Re: Login for bug reporting
Onsdag den 6. februar 2013 22:20:07 skrev Frank Reininghaus: considering that we get lots of duplicates for any reproducible bug, my impression is actually not that there are to many obstacles in the bug reporting process. Providing any kind of contact me via email/Facebook channel will only make it worse. I'm already spending a lot of time marking reports as duplicate/invalid or telling people that reporting bugs for KDE 4.8 or earlier is not quite as useful as they think. Please do not make it worse by lowering the bug reporting barriers. Anders
Re: Login for bug reporting
Torsdag den 7. februar 2013 10:29:53 skrev Myriam Schweingruber: On Thu, Feb 7, 2013 at 10:26 AM, Anders Lund and...@alweb.dk wrote: Onsdag den 6. februar 2013 22:20:07 skrev Frank Reininghaus: considering that we get lots of duplicates for any reproducible bug, my impression is actually not that there are to many obstacles in the bug reporting process. Providing any kind of contact me via email/Facebook channel will only make it worse. I'm already spending a lot of time marking reports as duplicate/invalid or telling people that reporting bugs for KDE 4.8 or earlier is not quite as useful as they think. Please do not make it worse by lowering the bug reporting barriers. How would the demand for having an account lower the amount of duplicates? The other way round: we already have a lot of duplicates with the current system, if the reports don't have to make an account anymore we would get even more useless reports. Noone /wants/ to create duplicates. Preventing bug reports not only prevents duplicates, it also prevents usable reports. If we want fewer duplicates, making it more likely that they are caught before reported is a better idea. Make the duplicate search step more efficient, for example by having it on a page of its own, so it can't be scrolled past as easily, and provide better information about using it. And what others can come up with... Anders
Re: Login for bug reporting
Torsdag den 7. februar 2013 10:37:38 skrev Christoph Cullmann: Beside, does the account generation not at least validate the E-Mail address, or? I mean, I have nothing against allowing people to login with their Google account or whatever if that is possible, but I would not like to see bug reports by idontc...@lala.org. Thus the idea of using a confirmation link. Anders
Re: Login for bug reporting
Onsdag den 6. februar 2013 21:52:53 skrev Alex Fiestas: On Wednesday 06 February 2013 20:36:33 Christoph Cullmann wrote: Hi, actually, if he has taken the obstacles of installing tens of megabytes of stuff, what was the problem with creating an account? Haven't it ever happened to you that you are buying something on the interwebs or checking some stuff and when you are asked to login/register you stop? It has happened to me hundreds of times, maybe because I'm lazy. I sympathize with this user. So do I. Wouldn't it be possible to send a confirmation link for a bug reported by someone not logged in? Anders
Re: kwalletmanager ui refactor
Søndag den 3. februar 2013 14:50:33 skrev Valentin Rusu: Hello, Lots of us are frequently using kwalletmanager to get/store the secrets for the ever extending sensitive information. We click it's icon to pop the main window, then double click the main wallet icon to pop another window, that will eventually go to the second display (that's my case). Perhaps you put aside a quick thought that this should be changed, but return to the task under hand. And then forget about this until you'll next need to use kwalletmanager. :-) During last days I finally sat down and did a ui-refactor and now kwalletmanager handles all the wallets inside a single, KPageWidget based design. A screen capture is far better than a hundred words so here it is: http://imgur.com/MD3GDxO Great to get rid of that extra window! What I think is why even the graphical representation of it? How many people have more than one wallet? And would they loose functionality if the option to switch was represented by a menu (Files-Wallet-)? Anders
Re: kwalletmanager ui refactor
Søndag den 3. februar 2013 16:51:49 skrev Thomas Lübking: On Sonntag, 3. Februar 2013 16:40:04 CEST, Anders Lund wrote: Great to get rid of that extra window! What I think is why even the graphical representation of it? How many people have more than one wallet? And would they loose functionality if the option to switch was represented by a menu (Files-Wallet-)? One could maybe conditionally hide the pageview (because the majortiy of ppl. will not be interested in 1 wallets but those who are will then likely prefer a more direct access?) Btw: does anybody actually use the systray thing? I need to see that window ~ once a week and then just launch the walletmanager (so the systray icon is disabled, but that's afaik not the default, is it?) I think it is on by default. I use it relatively often, but rarely more than once a day, and absolutely not every day. Anders
Re: Review Request: Rewrite Google's tracking URLs in search results
Søndag den 23. december 2012 14:34:59 skrev Thomas Fischer: On Dec. 23, 2012, 12:57 p.m., Anders Lund wrote: Wouldn't it be better to improve the userscripts plugin for KHTML? I have auserscript that removes the google tracking URLS in khtml, and there are probably similar scripts eg for facebook and apart from that a lot of other usefull scripts in userscripts.org. I do not understand the rationale behind targeting one specific website this way! Just my 2c :) userscripts plugin for KHTML Do you mean this one here? http://kde-apps.org/content/show.php?content=140676 It says it is no longer maintained. I will have a look ... Yes, but it basically works as far as implemented. There are some fairly low hanging fruits to pick, if someone wants to work on it. My code is fairly simple and more likely (I assume) to get accepted than a large solution like userscript. rationale behind targeting one specific website this way On the other hand userscripts by itself does not try to obstruct anyone in particular, which is what targeting google of facebook with specific code to alter their websites does. And websites can change their code at any time, in which case the hardcoded solution breaks unfixable until a new release can be made, whereas a javascript can be adjusted. It was my itch to scratch. Google is just the start. As I stated in the code as a TODO comment: more cases to add! That is my point, you can never hit all the various cases. Userscripts have a better chance with that, since there are quite a few more contributors ;) Kindly, Anders - Thomas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107867/#review23899 --- On Dec. 23, 2012, 11:09 a.m., Thomas Fischer wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107867/ --- (Updated Dec. 23, 2012, 11:09 a.m.) Review request for kdelibs. Description --- This patch adds the feature to KHTML to rewrite URLs that are used to track users. Right now, only tracking URLs from Google's search result are supported, but the list can be expanded (hard-coded right now). Example: A search for KDE may result in a list of links, including a link like http://www.google.com/url?q=http://www.kde.org/sa=Uei=YsYFfgOqAZzBQBCv ed=GEFANYNoNGusg=Y8BfN6qj0QYNHYJQQBEB When you follow this link, Google will transparently redirect you to http://www.kde.org, but still record your behaviour. The patch rewrites such links already in the HTML parsing phase, i.e. you never see the tracking URL, but instead the final URL only. The rewrite feature can be disabled through a setting, but there is no GUI for that yet. I was thinking about automatically detecting tracking URLs through a regular expression, but I guess running a regular expression check for every URL would be too time-consuming. I wrote the patch for 4.9.3 as this is the version I am using on the testing machine. I assume the affected classes haven't changed much in recent months, so it should be fairly simple to port to HEAD or future 4.11. Diffs - khtml/khtml_settings.h 0faec6d khtml/khtml_settings.cpp b5693b4 khtml/xml/dom_docimpl.cpp bb65a89 Diff: http://git.reviewboard.kde.org/r/107867/diff/ Testing --- Thanks, Thomas Fischer
Re: kdereview: bodega
On Onsdag den 24. oktober 2012 23:19:57 Andras Mantia wrote: Hi, Aaron J. Seigo wrote: Bodega I hope you are aware about the meaning of the name in certain countries. :) In Spain it is winery, while in Romania and probably some parts of Hungary it is the name of the cheap drinking places especially in little villages where people go for only one thing: to drink alchool (mostly hard ones). So here it has a negative connotation. Same here in Denmark -- Anders
strigi xml analyzers
This is probably the wrong forum to ask, but can someone point me to examples of strigi analyzers for xml files, for example svg or other xml based types? I gave up finding them in projects.kde.org :( -- Anders
Re: strigi xml analyzers
On Mandag den 17. september 2012 15:02:59 Vishesh Handa wrote: On Mon, Sep 17, 2012 at 1:00 PM, Anders Lund and...@alweb.dk wrote: This is probably the wrong forum to ask, but can someone point me to examples of strigi analyzers for xml files, for example svg or other xml based types? I gave up finding them in projects.kde.org :( Hi It would be best if you just directly looked at the existing analyzers in the libstreamanalyzers repository [1]. Thanks a lot! :) Could you elaborate on the kind of stuff you're looking to do? I ask cause if you're looking to writing a special file analyzer that can be used in Nepomuk, strigi may no longer be an option. I would like to write something that can get metadata from gpx files, so that I can see it in dolphin and elsewhere. Gpx files are GPsExchange files, containing waypoints, tracks and routes, and I would like to be able to see what/how much data, dates, bounding box and things like that. If there is a better way than writing a streamanalyzer plugin, I'll be happy to know :) [1] https://projects.kde.org/projects/kdesupport/strigi/libstreamanalyzer -- Anders -- Anders
Re: KDE SC 4.8.4 important problems
Den 10-06-2012 11:38, Peter Penz skrev: The issue has been tracked at https://bugs.kde.org/show_bug.cgi?id=268064 - updating Soprano to the latest master resolves the crash. But I don't know more about the root-cause of this. Probably a Nepomuk-related update missed a proper versioning-check of Soprano? I run a fully updated archlinux, and get these crashes too. So using kde 4.8.4 requires unreleased soprano ? :0 Anders
Re: DrKonqi improvement idea
Søndag den 11. marts 2012 11:26:53 skrev Niko Sams: Hi, I'd like to talk about an idea on how DrKonqi (which is a really useful thing btw) could be further improved. In short: DrKonqi shouldn't create bugs directly but talk to a layer between. DrKonqi - crashes.kde.org - bugs.kde.org crashes.kde.org is a new web application - a bit similar to bugzilla: - lists all reported crashes with intelligent filtering duplicates - developers can set duplicates - developers can link a crash to a bug (or create automatically a bug for a crash) - developers can enter a solution (that will be presented to the user that hits this crash) eg.: - update to version x.y - temporary workaround: don't click button x - you missconfigured x, see http://y.com how to fix - the developers are aware of this issue but have not yet fixed it, see http://bugs.kde.org/... for details - the bug is fixed but an update has not yet been released. Update to version x.y once it released. - comments can be added by users and developers (to ask how to reproduce etc) For the end user there could be the following scenarios: - user posts the crash, crashes.kde.org finds a duplicate crash in it's database and will tell the user on how to proceed (see possible solutions above) - user posts the crash, crashes.kde.org can't find an exact duplicate and will show the user all possible duplicates - user posts the crash, crashes.kde.org doesn't find a duplicate. User gets the possibility to subscribe to updates for this crash to get an email when a solution for his crash was entered by the developers One big difference in implementation I would propose: DrKonqi makes a *single* POST to crashes.kde.org including all information and then just shows a WebView where the server side can do anything. That gives greater independence of the used KDE version and changes on the server side. Advantages over current solution: - bugs.kde.org isn't filled with duplicates - crashes.kde.org can be specialized on crashes - sending a crash would not only help developers fixing that bug but also help the user by showing a solution for his issue. What software could crashes.kde.org run? I'm not sure, maybe a bugzilla installation or something custom written. Or some other bugtracking software. So, what do you think? Niko +1 I think communicating back to the user this way would be a great improvement on user experience wrt bug handling. Sounds like the communication would be much more/better structured than it is now. Anders
nepomuk restarting
Hi, I don't know if this is the right place for this, but: I experience once in a while a need to kill off nepomuk/virtuoso-t and restart it. This again means that most apps depending on it must be restarted, ie bangarang, dolphin, gwenview and plasma-desktop is in a somewhat broken state after restarting nepomuk. Would it be possible to make this happen automatically, like kdepim apps automatically reconnects when akonadi is restarted? Or signal that the service have been restarted to let applications know so that they can act? Nepomuk itself also have some issues with handling problems. If virtuoso-t is killed, it is not possible to display the nepomuk kcm. I know nepomuk is meant to Just Work in the background, but it is a painfull fact that this is not always the case. Even when nepomuk becomes perfectly stable, it would not hurt being able to handle it getting killed. -- Anders
Re: Review Request: Add KFontDialog-setSampleText()
I have a button that allows me to change the sample text in kfontview, KDE 4.7.4. In systemsettings font installer, I can rightclick the font view area and find a menu item to change the text in the context menu. On Torsdag den 8. december 2011, Kurt Hindenburg wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103357/ --- Review request for kdelibs. Description --- Currently there is no way to change the sample text in KFontDialog. I would like to change the sample text in Konsole to display characters that may appear similar in some fonts (iIlLoO0). Diffs - kdeui/fonts/kfontdialog.h 371345e kdeui/fonts/kfontdialog.cpp efd6a35 Diff: http://git.reviewboard.kde.org/r/103357/diff/diff Testing --- Compiled on master branch and testing in Konsole. Thanks, Kurt Hindenburg -- Anders
Re: Review Request: Add KFontDialog-setSampleText()
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103357/#review9409 --- Using KDE 4.7.4 I can just click and type there. - Anders Lund On Dec. 8, 2011, 4:11 a.m., Kurt Hindenburg wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103357/ --- (Updated Dec. 8, 2011, 4:11 a.m.) Review request for kdelibs. Description --- Currently there is no way to change the sample text in KFontDialog. I would like to change the sample text in Konsole to display characters that may appear similar in some fonts (iIlLoO0). Diffs - kdeui/fonts/kfontdialog.h 371345e kdeui/fonts/kfontdialog.cpp efd6a35 Diff: http://git.reviewboard.kde.org/r/103357/diff/diff Testing --- Compiled on master branch and testing in Konsole. Thanks, Kurt Hindenburg
Re: Review Request: Add KFontDialog-setSampleText()
On Jan. 1, 2012, 5:16 p.m., Anders Lund wrote: Using KDE 4.7.4 I can just click and type there. Thomas Lübking wrote: I guess it's by more about defaults, since the technical use of fonts has other demands (unambiguity) than the regular one (pretty) which the regular user however might not implicitly be aware of. I hope the option to get a view of the font is not limited to technicalities. For many people general readability and asteathics are important parameters as well! And the problem with iIlLoO0 could be considered important for general font usage too. - Anders --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103357/#review9409 --- On Dec. 8, 2011, 4:11 a.m., Kurt Hindenburg wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/103357/ --- (Updated Dec. 8, 2011, 4:11 a.m.) Review request for kdelibs. Description --- Currently there is no way to change the sample text in KFontDialog. I would like to change the sample text in Konsole to display characters that may appear similar in some fonts (iIlLoO0). Diffs - kdeui/fonts/kfontdialog.h 371345e kdeui/fonts/kfontdialog.cpp efd6a35 Diff: http://git.reviewboard.kde.org/r/103357/diff/diff Testing --- Compiled on master branch and testing in Konsole. Thanks, Kurt Hindenburg
Re: Review Request: Make kfmclient honor the user configured browser settings for local resources
On Onsdag den 28. december 2011, Dawit Alemayehu wrote: I disagree. Basically, if a user associates konqueror with anything else himself, your patch would disregard that and just fire up firefox. Yes exactly. The user consciously choose to do that. Why should we not honor that choice ? So long as we do not redirect any file management related request to another web browser, we should honor the user's choice. Otherwise, we are simply being inconsistent. Some things get redirected and somethings do not. It all seems arbitrarily decided. Anyways, our different views on this point should not hold up the fix for the reported bug. So with firefox as default browser, it should not be possible to associate konqueror with anything? -- Anders
Re: Suggestions for some KDE default options
On Tirsdag den 13. december 2011, Kevin Kofler wrote: Ingo Klöcker wrote: Markus made exactly the right reply, constructive (except for the whining bit) and to the point. You didn't. Your reply was not really helpful. In fact, I, as one of your esteemed list mods, find it outright insulting. I'm with Eike Hein. Don't feed the troll! Sending the trolls to the distro mailing lists like Markus did between the lines is NOT helpful, we can't use them any more over there than here! Those suggested defaults don't make any more sense in distros than upstream. Kevin Kofler On the other hand, being rude and patronizing towards a frustrated user trying to fix things does not help anyone either. Even if the suggestions are not well thought out, they are not posted here in a desire to be harmful, rather in a desire to use KDE software. -- Anders
Re: Suggestions for some KDE default options
On Tirsdag den 13. december 2011, Thomas Zander wrote: On Tuesday 13 December 2011 05.59.14 Anders Lund wrote: On the other hand, being rude and patronizing towards a frustrated user trying to fix things does not help anyone either. Even if the suggestions are not well thought out, they are not posted here in a desire to be harmful, rather in a desire to use KDE software. I want to comment on this meme that I've seen floating around for quite some time. The idea that since the user probably has clean motives, we should overlook bad behavior. This is an idea that is very dangerous and should be killed. KDE is a meritocrazy; we allow people in our midst based on what they can accomplish and how good they contribute to our projects. We judge people on their accomplishments, in other words. The suggestion to overlook bad behavior is therefore completely the opposite to our ideas of what makes KDE tick. A person that is insulting to other peoples accomplishments, and has no accomplishments to show of their own, is someone that thus breaks down our community. Or more directly; Ingo ok-ed a message into our core list that killed the motivation of quite a lot of people that I call friends and colleagues. I don't like that, I wish they be treated better. Just because a person tries, maybe even shows a desire to be helpful, doesn't mean (s)he gets to put down others. We are not a charity where being needy is the way in. We are not a church where forgiveness is the way in. We are a meritocrazy where personal accomplishments are the highest achievements. Have a nice day :) I don't suggest to overlook bad behavior, I suggest to meet it with dignity. -- Anders
Re: The future of Power Management - together with Activities
On Lørdag den 1. oktober 2011, Dario Freddi wrote: Hello all, and sorry for cross-posting. Me and Bjorn have been discussing extensively about how to improve the current situation with Power Management in KDE. We focused on simplicity, still without losing power-user features. And we have a plan I'd like to share and get some feedback on. The first, important part: we plan to remove the Warning step and the possibility of creating profiles manually. The reason behind this choice will be clearer later. So we will have just 3 static profiles: one for AC power, one for the PC running on battery, one for the PC running on low battery. At the same time, the combobox for selecting a profile in the battery applet will be removed. It will, although, be replaced by a toggle button for inhibition: by enabling/disabling it, power management features regarding screen suspension, notifications and screen power management will be suspended. Technically speaking, the battery applet will trigger a full inhibition on the power manager while this button is still on. And how do we cope with the users wanting to have very specific behavior in certain situations? This is where activities kick in. We will allow to configure a profile for each activity, if the user wants to, in two different ways: action override and profile override. Let me expand. Suppose you want to have an activity named Sleep, in which you watch a movie, and the PC will shutdown after 90 mins of inactivity. In this case, you would just specify to override the Suspend Session action. Or, you want to have an activity where you always want a profile which lets you run at full speed. You can define a whole new profile for it. Bottom line: manual profiles become activity profiles. Hopefully, this solution will please everyone and will make activities even more useful. Do you like it? More suggestions? Speak now or shut up forever! I only ever created one manual profile, and I actually have an activity that goes with it. In al other cases, I do with the standard profiles. So to me your solution sounds fine. -- Anders
Re: The future of Power Management - together with Activities
On Lørdag den 1. oktober 2011, Scott Kitterman wrote: I don't understand how creating a new activity represents an improvement to the user. If I understand the proposal correctly the user will only use the power manager to change existing profiles and if they want to create an alternative profile they will have to us something that is not the power manager. I have a usecase that illustratess it: I created a power management profile for using on my boat, where low power consumption goes with staying up as long as possible. To accomplish that, I also created an activity which have no networkdependent plasmoids or applications running (or anything resourcehungry, except for relevant stuff) With the proposed system, they will be naturally paired, which is very nice. -- Anders
Re: Minor Point Relase Policy
On Søndag den 27. februar 2011, Albert Astals Cid wrote: Hi, the release-team has written a minor point release policy for KDE main modules. You can find it at http://techbase.kde.org/Policies/Minor_Point_Release_Policy As far as we know it covers what we already do, just makes it a bit more official and standarized. Albert I'm sure you do not mean These releases must only contain: Severe bugs: security vulnerabilities, severe regressions from previous releases, data loss bugs -- Venlig hilsen, Anders
Re: Minor Point Relase Policy
On Søndag den 27. februar 2011, Albert Astals Cid wrote: I'm sure you do not mean These releases must only contain: Severe bugs: security vulnerabilities, severe regressions from previous releases, data loss bugs Added a Fixes for in front. Yes, that looks more correct :) -- Venlig hilsen, Anders
Re: Profiles for all KDE-applications
On Lørdag den 26. februar 2011, Andreas Hartmetz wrote: On Saturday 26 February 2011 10:58:23 Jonathan Schmidt-Dominé wrote: Hi! In Mozilla-applications so called “profiles”, sets of user-configuration, are a quite common feature, Konqueror implements them, too. But wouldn't it be possibe to provide this feature for all KDE-applications by changing KApplication, KConfig and friends? It should be possible to pass some parameters at startup to use a specific profile, KApplication would recognize the paths and KConfig would adjust its directories and independendent sets of configuration would be used. Those configurations could be saved somewhere in .kde/extra-profiles or something like that. It should work for most applications, only a small minority does not keep its configuraion in the user's .desktop-files. Some simple GUI-dialogs and it would be at least as good as Mozilla's support. I think it would be useful for many applications, e.g. Kopete or Amarok. Any comments? I find the idea interresting, I was just thinking that I use marble in quite a few different ways. Tha's a really advanced feature, and it's already available to advanced users. You only have to set a different $KDEHOME before starting an application. Changing KDEHOME changes more than the single application, so that is not viable. Prepending the search path would be smarter. Or use the --config alternative config file option that kapplication provides ;) Maybe apps could just look in the existing config filesystem for alternate configs, and offer to switch from the application menu? That could be done in kapplication, and the required menu items provided as standard like other menu itmes in KDE. -- Venlig hilsen, Anders
Re: the next step on the desktop
On Tirsdag den 1. februar 2011, Aaron J. Seigo wrote: On Monday, January 31, 2011, Anders Lund wrote: Please do not make everything the desktop, as long as it is not keyboard accerssible! I avoid using plasma-notebook, since it is an interface for clickers. please do not make knee-jerk reactions. please create informed opinions, ask questions reasonably and i promise that you'll get informed, reasonable answers. Please do not be rude, you end up making me feel bad every time you answer any question or comment I make. If you can not handle that I do not always see things same way you do without being unnice, please ignore me. so ... SAL is keyboard navigable. keyboard shortcuts can get focus to any given widget. the thing i did notice that isn't keyboardable when testing right now is tab-ing out of the top shortcut strip. My experince with SAL so far is that I start it, look at it and do not know what to do except clicking in the entry field, which makes me immediately go back to the normal desktop. For SAL to work like that, the search entry should have focus when it is displayed, which is not currently the case. It it would do that, it would be usable, and in fact be what I have been looking for for long time: A SAL that is in the center and having space enough to make it really easy to pick the desired result. Of course there are other concerns: The current dashboard display is not working well, the background is too noisy behind it, and very much I actually have very valuable widgets on my desktop that I use often, and that I can display or hide hide with a single shortcut. Hey Plasma have very great value, thanks again for that :) So the message is not that I am against improvements or evolution, rather that I strive for them being usable for everyone, including keyboard users. The good keyboard support is one of my favorite KDE features! ad the intention is not to make everything the desktop :) Good :) -- Venlig hilsen, Anders
Re: the next step on the desktop
A stray thought on making plasma-netbook easier to use: have a shortcut to the search field, and put it in the text, so it reads F2 to search instead of Search (given F2 is the shortcut). That way it will be visible to the user what to do. -- Venlig hilsen, Anders
