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: 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: 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: 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 > >
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: 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
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
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 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: 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
Re: Review Request: Rewrite Google's tracking URLs in search results
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107867/#review23899 --- 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 :) - Anders Lund 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=U&ei=YsYFfgOqAZzBQBC&ved=GEFANYNoNG&usg=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: 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=U&ei=YsYFfgOqAZzBQBC&v > > ed=GEFANYNoNG&usg=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: 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: 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: 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 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 . Thus the idea of using a confirmation link. Anders
Re: the next step on the desktop
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. Such interfaces may make sense for tablets and phones, NOT for anything with a keyboard! -- tia, 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
Some text was lot in the paragraph below due to kmail freezing during editing this mail. 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. Missing text: Currently I can type one shortcut and enter a few characters to launch an application, search or other action that krunner supports. For SAL to work like that, the search entry should have focus when it is displayed, which is not currently the case. -- 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
Re: Keyboard shortcuts get wild.
On Lørdag den 5. februar 2011, Mark wrote: > Hi, > > let me first point you to this image (kde 4.6.0) : > http://img89.imageshack.us/img89/5398/rightmousebuttondesktop.png > > Oke, first one shortcut in that image. > I consider myself a experienced computer user in both windows and linux but > today i learned new shortcut things. > ALT + d, a (which is pressing ALT and type 'd' and 'a' while ALT is > pressed.. i didn't knew any combinations like that before) > > Now lets consider what i wanted to do. What i wanted is opening the dialog > to add widgets to my desktop.. that's it. Now that shortcut isn't working > and i reported that here : https://bugs.kde.org/show_bug.cgi?id=265527 but > i wonder what the rationale is behind ALT + d, a... > > ALT, i can understand.. but D and A..? What does D mean? What does A mean? > The thing i want to do is "open the dialog to add widgets" and to describe > it simple i would say "add widgets" but i can't find any of that back in > the shortcut.. I would have expected something like this "ALT + a, w" for > "adding widgets" and "ALT + a, a" for adding activities... > > One that is obvious is the desktop settings is ALT + d, ALT + s even though > ALT + d, s is also working so i suspect there is a bug in there. However, > it's not consistent with other setting shortcuts. You can see the desktop > settings as "properties" and in dolphin they use "ALT + Return" for that. > (what i find odd is that ALT + Return opens dolphin when not opened..) > > so perhaps it's time to take a real good look at all our shortcuts and > define some generic application shortcuts that are the same in every > application that makes KDE SC. > > Just a little brainstorm. > What do you think? I find it confusing that Plasma uses two formats, some are "ALT + D, ALT + A" (Activities), some are "ALT + D, A" (add widgets). The latter does not work btw, on my system it shows the activities pane. "ALT + D, L" (lock widgets) works, but i find that spooky - if I press ALT + D, how long will it take berore reset? It's like a hidden menu :o Plasmoids that can be configured all claims "ALT + D, S", but of course it does not work for all of them - in fact it works in some cases for the latest clicked plasmoid /on the desktop/ -- those on the panel can not be reached by keyboard in my experience. Since there is no other concept of a "current" plasmoid, this is rather spooky too, I have to click an applet to know that its config dialog will popup on "ALT + D, S" - if it is a ??? (yaWP or fading calender works, but eventlist does not). All in all, it is safer to be a clicker, at least when it comes to configuring plasmoids... Hm, looks like there is room for improvement :-) -- 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 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: Profiles for all KDE-applications
On Lørdag den 26. februar 2011, Anders Lund wrote: > Or use the --config > option that kapplication provides ;) ... but then, I wonder if this works in any application, marble or kwrite for example does not appear to care ... -- Venlig hilsen, 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 Onsdag den 2. marts 2011, Stefan Majewsky wrote: > On Wed, Mar 2, 2011 at 10:40 AM, Marco Martin wrote: > > what about having two config file, a primary one that is the "real one" > > and a set of secondary ones that can be loaded and changed on the fly > > depending on activity change? > > Perfectly possible from the technical side thanks to KConfig, but: > Upon changing a configuration parameter, how should the user decide > whether this change is local to the activity or global to all > activities (i.e. whether it goes into the activity-specific config or > the "real one")? That is a good argument for this being a feature for the application to handle - by offering the user a way to know what she does. -- Venlig hilsen, Anders
Re: Review Request: Ark doesn't recognize zip files from websites when using KHTML
On Fredag den 20. maj 2011, Commit Hook wrote: > --- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101379/#review3411 > --- > > > This review has been submitted with commit > dffd5950b35ead8c14c5cf3a2495be5f8b7b9a1f by Dawit Alemayehu. > > - Commit > > On May 17, 2011, 6:26 p.m., Dawit Alemayehu wrote: > > --- > > This is an automatically generated e-mail. To reply, visit: > > http://git.reviewboard.kde.org/r/101379/ > > --- > > > > (Updated May 17, 2011, 6:26 p.m.) > > > > > > Review request for kdelibs and David Faure. > > > > > > Summary > > --- > > > > If one clicks on a link to a zip file when using khtml, the request is > > forwarded to the container application application for handling, in this > > case Konqueror. The container application, konqueror, then creates an > > instance of KonqRun to determine the content-type of the request so that > > the request can be handled by the proper application. Unfortunately, > > KonqRun relies on functions in its parent class, KParts::BrowserRun, > > which do not do the right thing when putting an ioslave on hold for > > reuse at the moment. This patch is an attempt to fix the problems in > > KParts::BrowserRun. Maybe this is also why using kdewebkit in konqueror is broken when clicking on any link to a pdf/od*/whatever non-html file? -- Anders
