Re: Formal complaint concerning the use of the name System Settings
Hi Thomas. Sorry for stepping in here, but are you really discussing to present the users different names for applications (not the bins, but we're talking about joe) under different circumstances so if i'd tell a user to run foo he won't be able cause it's called bar in his DE? Yes, that is what this extension would allow. It's a powerful tool, and any powerful tool can be abused. The presumption of course that people choosing the names will choose them sensibly. For example, in the System Settings case, in KDE, there could be System Settings and Gnome System Settings, with the former being the KDE version; similarly in Gnome. And I think it's better than having two identically named System Settings, or having both of them always prefixed, i.e. KDE System Settings and Gnome System Settings. For example, consider the user asks you how he can change the fonts. You would simply tell him to open System Settings, and it would open his desktop's native configuration tool, which should work even for non-native applications IIRC. On the other hand, if he says that he changed something, but it didn't work in that particular application, you would tell him to open the other System Settings (better than telling him kcmshell4 whatever!) The .desktop file already knows a name and a generic name and the representation (aka runner) could be smart enought to detect pseudo doublettes and use the generic name by default and attach the non generic name (or, as LLOD the binary) for clarification if necessary or just to be honest. This doesn't solve the original problem. The two System Settings in fact have the same Name. It is also harder to implement, and the behavior is non-obvious. You're currently only talking about solutions covering LANG=C but you cannot possibly expect translators to avoid such clashes in their translations if the application name does not contain some trademark. Eg. system settings as well as configuration center could easily end up as Systemeinstellungen in German - simply cause it's (iirc - bee a long time) the winblows term - some languages might not even leave any options in some cases. My proposal is not tied to English in any way. The individual Specific-DE- prefixed keys would come localized, just like the non-prefixed keys. I don't see how choosing sensible names in other languages could be much harder than in English. Regards, Ambroz On Tue, Jul 26, 2011 at 8:14 PM, Thomas Lübking thomas.luebk...@gmail.com wrote: Am Tue, 26 Jul 2011 13:45:26 +0200 schrieb Ambroz Bizjak ambr...@gmail.com: (Mark, sorry if you're getting this twice, I clicked the wrong Reply button the first time...) Hi Mark, I understand your concern, but I don't consider it an issue. There is a downside to your proposal compared to mine, which is that it only allows a specific value to one (!) DE. For example, with mine, you could have: Name=Some Generic Name Specific-KDE-Name=Name in KDE only Specific-GNOME-Name=Name in GNOME only Specific-XFCE-Name=Name in XFCE only Sorry for stepping in here, but are you really discussing to present the users different names for applications (not the bins, but we're talking about joe) under different circumstances so if i'd tell a user to run foo he won't be able cause it's called bar in his DE? The .desktop file already knows a name and a generic name and the representation (aka runner) could be smart enought to detect pseudo doublettes and use the generic name by default and attach the non generic name (or, as LLOD the binary) for clarification if necessary or just to be honest. If the runner isn't smart enough to avoid presenting clashes to the user, that's a runner bug - no matter what caused it in this particular case. You're currently only talking about solutions covering LANG=C but you cannot possibly expect translators to avoid such clashes in their translations if the application name does not contain some trademark. Eg. system settings as well as configuration center could easily end up as Systemeinstellungen in German - simply cause it's (iirc - bee a long time) the winblows term - some languages might not even leave any options in some cases. Cheers, Thomas
Re: Formal complaint concerning the use of the name System Settings
Hi Thomas, I hope you are aware that my proposal is a technical solution and not a social one. I cannot predict the social aspects of it. More specifically, it is mechanism that allows for solutions to problems. If the problem is two things from different DEs have the same name, then a direct solution to the problem is make the names different. And I have proposed a mechanism for doing exactly that, and doing it in a simple an intuitive way. Moreover, the mechanism is really generic as it would apply to all keys in a .desktop file, not only a Name, so you can't ever claim that it's a hack. If an application has a different name under different DEs, that's not abuse but error by design (sorry, i don't mean to be offensive) Just no. It's abuse by the application author. Additionally, please stop arguing my solution based on purely hypothetical cases. Applications DON'T AND WOULD NOT have different names under different DEs, except for the very few specific cases where disambiguation is required. This doesn't solve the original problem. Yes it does. They will certainly not share the same binary name or we've a _real_ problem. (Or not, since there will be only one target for the application link anyway ;-) I'm not too sure what solution you're arguing here for, but I believe that if you looked at this specific case (in particular the .dekstop files) with a little more detail you would realize you're talking nonsense. To repeat the example, if translator (a) translates the KDE .desktop file, translator (b) the gnome one and they don't coordinate ... I'm pretty sure all the translators problems would be solved by mailing all translators something like: Please take a look at systemsettings.desktop, and choose the Specific-KDE-Name translation to what the System Settings application should be called from within KDE (probably what was previously used for Name), and then choose the Name translation to what the System Settings application should be called from other desktop environments, which would probably mention KDE somewhere for disambiguation with the other desktop's settings application. possibly mentioning other clashing cases. - If clashes are (apparently) an existing problem, they need to be avoided at the end of the chain where they can be spotted for sure and not on the start where we just hope we (and everybody else!) did everything ok My proposal does not provide a mechanism for detecting clashes, only one for resolving them. I'm sure that with a little attention from application developers and listening to users, relevant clashes will quickly be detected (as was the System Settings case). Regards, Ambroz On Tue, Jul 26, 2011 at 9:10 PM, Thomas Lübking thomas.luebk...@gmail.com wrote: Hi Ambroz, (and everybody else of course) Am Tue, 26 Jul 2011 20:39:27 +0200 schrieb Ambroz Bizjak ambr...@gmail.com: Yes, that is what this extension would allow. It's a powerful tool, and any powerful tool can be abused. If an application has a different name under different DEs, that's not abuse but error by design (sorry, i don't mean to be offensive) Leaving aside systemsettings, what if i tell somebody to run marble (it's like google-earth!) but he then starts some solitaire game (because there is eg. a solitaire game like this on OtherDE and marble is named KDE's google-earth clone ;-) he'll be pissed and i'll be lost. This doesn't solve the original problem. Yes it does. They will certainly not share the same binary name or we've a _real_ problem. (Or not, since there will be only one target for the application link anyway ;-) It would also be possible to choose System Settings as generic name and KDE Settings as non generic one. The latter would only be presented for clarification (if the runner wanted) It is also harder to implement, and the behavior is non-obvious. a) i don't think so b) that's not an excuse. My proposal is not tied to English in any way. No, but it is tied to the ppl, knowing about an and resolving an actual clash which i doubt translators can be expected to be. The individual Specific-DE- I wasn't restricting my concerns to the we already know about an existing clash in LANG=C. The very same issue can _easily_ arise onlny in a particular translation. To repeat the example, if translator (a) translates the KDE .desktop file, translator (b) the gnome one and they don't coordinate, they might pick the very same translation for control center and system settings (unless as mentioned there's a trademark in the string what renders the entire approach useless since that could be added automatically anyway) This might happen even though there are similar strings in German (surprise, since english is just degene... strike that ;-) because as mentioned the translators might have other references in mind. In other languages there might not even be any variants of this item. - If clashes are (apparently) an existing problem, they
Re: Formal complaint concerning the use of the name System Settings
Hi Thomas, I'm not saying that the issues you have exposed do not exist. They are however minor in nature and do not invalidate my solution. You call that technical and not social? My proposal is technical. I have only mentioned the social aspects when you have risen social issues about it. You'll at best be able to resolve risen clashes. Yes, exactly. That's what the original problem was. The original problem was not We have to prevent ALL name clashes; rather, it was System Settings clashes with a Gnome application. So I think we should stay on point here and not wander into some utopian land you seem to be imagining. And in a quite workload causing way - systemsetting would eg. require an KDE System Settings entry for _every_ desktop but KDE ... You are mistaken here. I am afraid you just got a glimpse of my idea which was really a case pointing out an issue in some other inferior idea. Actually only this would be required in the System Settings case: Name=KDE System Settings Specific-KDE-Name=System Settings and would result in the program being called System Settings in KDE, and KDE System Settings in everything else, including DEs which do not know anything about my proposed extension. I suggest you look at the whole mail history. My original proposal is here (but I reversed the names there accidentally, sorry about that): http://lists.kde.org/?l=kde-core-develm=131160689716557w=2 Regards, Ambroz On Tue, Jul 26, 2011 at 10:31 PM, Thomas Lübking thomas.luebk...@gmail.com wrote: Am Tue, 26 Jul 2011 21:53:48 +0200 schrieb Ambroz Bizjak ambr...@gmail.com: Hi Thomas, I hope you are aware that my proposal is a technical solution and not a social one. No, it's probably not - see end of mail. If the problem is two things from different DEs have the same name, then a direct solution to the problem is make the names different. No, the solution of ambiguity is disambiguation - not adding more strings which could easily end up as ambigious. Again: the .desktop files already contain various identifying attributes. a) name b) generic name c) executable d) description e) (icon, but we'll leave that out) Whether your representation prefers the generic or non generic name is matter of pers. pref. but you can detect a clash and resolve it by adding more info. LLOD is the binary executable (in doubt including path parameters) since that /has/ to differ for different entries. And I have proposed a mechanism for doing exactly that, and doing it in a simple an intuitive way. By adding an extra key for every possible DE... Moreover, the mechanism is really generic as it would apply to all keys in a .desktop file, not only a Name, so you can't ever claim that it's a hack. a) how does that make/resolve it being a hack? b) where did I imply it was? If an application has a different name under different DEs, that's not abuse but error by design (sorry, i don't mean to be offensive) Just no. It's abuse by the application author. So having different names on different DEs is not the intention of your approach (then why do you?) but abuse by the application author (where you drop accidents by the author/the translators...) except for the very few specific cases where disambiguation is required. Ans this is what i'm discussing. I didn't think of developers/translators deliberately confusing users at all. This doesn't solve the original problem. Yes it does. They will certainly not share the same binary name or we've a _real_ problem. (Or not, since there will be only one target for the application link anyway ;-) I'm not too sure what solution you're arguing here for, but I believe that if you looked at this specific case (in particular the .dekstop files) with a little more detail you would realize you're talking nonsense. So you imply that (in this particular case) the gnome application and the KDE application share the exact same binary executable path as well as each and every other identifying attribute? Well, as mentioned before there is then no problem at all, since the user will run the very same application regardless of which icon (of that only one should exist anyway) he clicks. (of course the new problem would be that installing gnome would wipe parts of KDE...) Otherwise i am not talking nonsense at all. I'm pretty sure all the translators problems would be solved by mailing all translators something like: ... My proposal does not provide a mechanism for detecting clashes, only one for resolving them. I'm sure that with a little attention from application developers and listening to users, relevant clashes will quickly be detected (as was the System Settings case). You call that technical and not social? Your approach relies on perfect communication _before_ a clashing release. That sounds more like unrealistic than generic. Sorry. You'll at best be able to resolve risen clashes. And in a quite workload causing
Re: Formal complaint concerning the use of the name System Settings
Hi Thomas. I think you didn't get what I said in the first place. The runner (the menu, whatever) has to ensure the disambiguation. Whether starting form the generic or non generic name doesn't matter at all. Okay, I get it now, thanks for clarifying. But please provide an example of how you would use it to resolve the System Settings case, for instance. I can't think of one. Assume that both applications have Name=System Settings - that is if KDE refuses to change its name and Gnome doesn't back away and revert to some other name. What would the .desktop files look like? Maybe something like this (KDE): Name=System Settings GenericName=KDE desktop configuration and Gnome: Name=System Settings GenericName=GNOME desktop configuration Suppose the user has the menu in the Name mode. Then your solution would, assuming both are present, result in there being KDE desktop configuration and GNOME desktop configuration - both (!) in KDE and GNOME (Name was ambiguous so GenericName was displayed instead). I hope we agree that is confusing for new users. Alternatively, there would be System Settings (KDE desktop configuration) and System Settings (GNOME desktop configuration), possibly the text in parentheses being subscribed instead. This is a little less confusing, but still confusing compared to just System Settings and GNOME System Settings, where System Settings, the native tool, is clearly preferred. And if the menu is in the GenericName mode, you would get KDE desktop configuration and GNOME desktop configuration, which is, again, confusing. Regards, Ambroz On Tue, Jul 26, 2011 at 10:39 PM, Thomas Lübking thomas.luebk...@gmail.com wrote: Am Tue, 26 Jul 2011 22:27:40 +0200 schrieb Ambroz Bizjak ambr...@gmail.com: Additionally, I make the following points on your proposed solution: My solution can do everything that the solution you are proposing No. Can't. The runner/startmenu (call it whatever you want) can effectively prevent clashes - what some extra string can only hope to achive (based on social engineering) Your solution (as far as I get it) assumes a specific interpretation of the Name and GenericName fields. No. It assumes that the .desktop files differ in some identifying attribute, It's just that some DEs (and distributions) use the Name field for the primary name in the menu, while some use the Name field. I think you didn't get what I said in the first place. The runner (the menu, whatever) has to ensure the disambiguation. Whether starting form the generic or non generic name doesn't matter at all. Cheers, Thomas
Re: Formal complaint concerning the use of the name System Settings
Hi Thomas, Additionally, I make the following points on your proposed solution: My solution can do everything that the solution you are proposing (if that is a solution at all). So if anything, it is techically on the same level. Your solution (as far as I get it) assumes a specific interpretation of the Name and GenericName fields. It's just that some DEs (and distributions) use the Name field for the primary name in the menu, while some use the Name field. Personally, I prefer the Name option where the menu shows the actual name of the application. This is also the case in other desktops, for instance Windows. Any disambiguation you attempt to do only on the basis of the Name and GenericName will behave differently, depending on what menu representation is in use (and there is *no* standard - some DEs use one, some the other, most allow you to switch, and even some distros change the default), and you won't have full control over the naming of the menu entry - which you do have with my solution (except for the Name-vs-GenericName thing), and which is necessary for proper disambiguation of clashes. Regards, Ambroz On Tue, Jul 26, 2011 at 9:10 PM, Thomas Lübking thomas.luebk...@gmail.com wrote: Hi Ambroz, (and everybody else of course) Am Tue, 26 Jul 2011 20:39:27 +0200 schrieb Ambroz Bizjak ambr...@gmail.com: Yes, that is what this extension would allow. It's a powerful tool, and any powerful tool can be abused. If an application has a different name under different DEs, that's not abuse but error by design (sorry, i don't mean to be offensive) Leaving aside systemsettings, what if i tell somebody to run marble (it's like google-earth!) but he then starts some solitaire game (because there is eg. a solitaire game like this on OtherDE and marble is named KDE's google-earth clone ;-) he'll be pissed and i'll be lost. This doesn't solve the original problem. Yes it does. They will certainly not share the same binary name or we've a _real_ problem. (Or not, since there will be only one target for the application link anyway ;-) It would also be possible to choose System Settings as generic name and KDE Settings as non generic one. The latter would only be presented for clarification (if the runner wanted) It is also harder to implement, and the behavior is non-obvious. a) i don't think so b) that's not an excuse. My proposal is not tied to English in any way. No, but it is tied to the ppl, knowing about an and resolving an actual clash which i doubt translators can be expected to be. The individual Specific-DE- I wasn't restricting my concerns to the we already know about an existing clash in LANG=C. The very same issue can _easily_ arise onlny in a particular translation. To repeat the example, if translator (a) translates the KDE .desktop file, translator (b) the gnome one and they don't coordinate, they might pick the very same translation for control center and system settings (unless as mentioned there's a trademark in the string what renders the entire approach useless since that could be added automatically anyway) This might happen even though there are similar strings in German (surprise, since english is just degene... strike that ;-) because as mentioned the translators might have other references in mind. In other languages there might not even be any variants of this item. - If clashes are (apparently) an existing problem, they need to be avoided at the end of the chain where they can be spotted for sure and not on the start where we just hope we (and everybody else!) did everything ok. Cheers, Thomas
Re: Formal complaint concerning the use of the name System Settings
On Tue, Jul 26, 2011 at 11:24:26PM +0200, Ambroz Bizjak wrote: Alternatively, there would be System Settings (KDE desktop configuration) and System Settings (GNOME desktop configuration), possibly the text in parentheses being subscribed instead. This is a little less confusing, but still confusing compared to just System Settings and GNOME System Settings, where System Settings, the native tool, is clearly preferred. i would argue that thomas' solution is better, because it is more explicit. your automatic preference for the desktop's native settings app is counterproductive for the user, because he sees ah, system settings and wtf is this?. he ignores the latter, and is frustrated by the result. in thomas' variant otoh he sees *two* wtf?s, and *has* to research it, understand the underlying problem. this is a requirement of the reality we present him with, so that outcome is *good*.
Re: Review Request: Fix logic with clear-button animation in klineedit (notably at first try) and address bug 268898.
Details: - fixes the somewhat incorrect logic in KLineEditButton::animateVisible - simplifies KLineEdit::updateClearButtonIcon consequently. Please test this also when using Konqueror and edit fields (e.g. login boxes). There have been some bad regressions about KLineEdit popping up in Konqueror, e.g. bug:246513. There is also one more regression about the return handling that I can't find at the moment (Andrea?). And while I'm at it here is another one: the following HTML fragment will have a damaged drawing of the line edits which will go away when you hover the broken place with the mouse. For me it looks like the clear button was originally drawn at that place and then it was removed because the input is disabled. I only managed to create a small self-contained testcase right now so there is no bug report yet. Will add that tonight. Eike !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.1//EN http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd; html xmlns=http://www.w3.org/1999/xhtml; xml:lang=en head titleDisabled button test/title meta http-equiv=content-type content=text/html; charset=utf-8 / /head body table trth colspan=2With table around/th/tr tr tdlabel for=n_nameName:/label/td tdinput id=n_name type=text name=n_name size=60 value=Entry that needs some space readonly=true //td /tr /table input id=n_name2 type=text name=n_name2 size=60 value=Another entry that needs some space readonly=true / /body /html
Re: Trouble with udisks-daemon caused by solid
On Tuesday 26 July 2011 19:48:06 Andreas Roth wrote: With the help of the amarok developers is found the piece of code, which triggers this issue. In amarok/src/MediaDeviceCache.cpp, function MediaDeviceCache::slotTimeout() calls Solid::Device::listFromType, which does some dbus/udisks magic and this causes the trouble. I haven't gone into the solid code to check what might be wrong there. Well, I guess the real question is why does Amarok poll in the first place? libsolid is doing what it's supposed to do: if you query a list is asks the system for it (in that case udisks). So obviously if you constantly ask the system you get the system component always eating CPU. I would advise against having this kind of libsolid call triggered by a timer. libsolid provides the necessary signals to let you know when a new device appeared or disappeared. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Formal complaint concerning the use of the name System Settings by GNOME
On 2011-07-23 Matthias wrote: On Fri, Jul 22, 2011 at 5:53 PM, Jeremy Bicha jbi...@ubuntu.com wrote: On 22 July 2011 17:17, Ben Cooksley bcooks...@kde.org wrote: To be more specific about the problem, installing kde-workspace to a GNOME installation results in 2 indistinguishable apps named System Settings and 2 named System Monitor. On Ubuntu at least, if I want the GNOME version, I have to remember to click the first System Monitor but the second System Setting which is awfully frustrating. Here's a screenshot from my Ubuntu install: https://launchpadlibrarian.net/75745040/Gnome%20Shell%20screnshot.p ng This is what happens when you mix and match bits and pieces from different operating systems. There is really not much that can be done about it. Since that is what both KDE and GNOME are trying to do: build complete, self-contained systems. Arguably, KDE is a little further along, with their big monolithic modules like kde-workspace that drag in most of the desktop, while GNOME apps can often still be installed without much of the desktop. Oh, come on. Both projects do that because of some incredibly silly attitude where everything that's from the other side is evil. And while that attitude is not universal. this tread (starting with the tone of Ben's mail) shows clearly many people still have that silly idea which leads to idiotic things like two calculators, two places to configure the language of the apps etcetera. How far have we, Free Software contributors, sunk, if KDE and GNOME apps work better under and integrate better in Windows and Mac OS X then they do ON THE SAME OS running in each other's desktop? I say VERY DEEP. Wake up. THe user doesn't give about the toolkit their app is written in. And they HATE the confusing situation KDE and GNOME purposely create (yes, it's on purpose and you all know it) by needlessly duplicating things and making it harder to run apps from one in the other. We've all seen countless installations of either KDE or GNOME where apps 'from the other side' look and work horrible. If KDE and GNOME can use the native Mac and Windows file dialogs, why can't they use each others dialogs? To name just one silly thing... Imho Ben's mail and the tone there-in was inpolite and uncalled for. And so was the tone many responses. Sigh. I'd like to suggest that the GNOME developers consider changing the public name of their app to System Preferences. This matches the Mac OS X design and arguably GNOME follows some parts of OS X design. Furthermore, it is more in line with Gnome 2's SystemPreferences and SystemAdministration. That is an absurd proposal. What next, rename gnome-terminal to 'Commandline Window' because Xfce also ships a 'Terminal' ?! Generic names don't come with exclusive ownership... Each desktop team should stop picking such generic names. gnome-terminal is fine, so is Konsole. Terminal should probably be renamed. NetworkManager is a braindead name, System Settings implies far more than it accomplishes (it can't handle much 'system settings') so it doesn't seem very smart either. Shaun's proposal is a work-around which would probably be 'good enough' but the root cause is that all DE teams try to create their own little world, going LALALA I DON'T SEE YOU about the rest of the world. And as has already been pointed out, offering the user a meaningless choice between 'System Settings' and 'System Preferences' is no less of a failure than having 2 identical items. That I agree with. KDE systemsettings has made a good step, being able to configure some aspects of GNOME apps (make them integrate better in a Plasma workspace). More of that is needed on both sides, OR a nice, generic config tool should be written which handles everything on both sides. Grtz Jos signature.asc Description: This is a digitally signed message part.
My Plans, Your Plans: Berlin Desktop Summit
hi :) BDS is coming up rather quickly and i've been doing some personal planning for it today. i realized in one of those i just realized the obvious, doh! moments that i have very little idea of what others are planning and hoping for the event. it was a quick hop from there to realize that probably nobody knew what i planned and hoped for either. given that this is one of the most important events in KDE's annual calendar, this was a little shocking to me once i thought about it. i'd like to help make BDS a raging success this year for us (and i'm sure you all want and expect the same :) and it would help if i (and others) could arrive with some idea of what we're all arriving with in terms of expectations. so .. here are my primary goals: * push Plasma further forward by meeting with others who are contributing in person (ok, that one was probably obvious :) * engage with others involved with our goals set out at Platform 11 for KDE Frameworks and move that forward with them. a concrete personal goal: have the Frameworks branches set up in kdelibs and kde-runtime and merge the libplasma2 branches into them. * share our goals for Plasma Active more openly and explicitly with other people in the KDE project. * promote organization and leadership efforts within our community (this is reflected by my presentation topic :) * ensure that we get reasonable promotional coverage for BDS: timely content on the dot, live blogging and microblogging ... * have an enjoyable time with everyone who shows up :) ok, so there you go. more than you may have wanted to know about my plans and goals for BDS. i'd enjoy having more goals than the above, but it's already a lot to accomplish in such a short time there. trying to stay somewhat realistic ;) i'm VERY interested in what you are hoping and planning for from your own attendance at BDS. please share those goals so that we can all arrive more mentally prepared for what is in store. p.s. i don't think we should try and discuss the content of our plans in this thread, as that is obviously what we'll do at BDS :) just knowing what each other's agendas are, even in sketch, is valuable ... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Review Request: Fix KGlobalSettingsTest failure
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102098/ --- Review request for kdelibs, Aurélien Gâteau and David Faure. Summary --- Since commit b064749a754ec358170ecb7f19828e4216f6e965, KDE palette and font settings are only used when running KDE apps in a full KDE session. This makes KGlobalSettingsTest fail if the test is not run in a full KDE session, see http://my.cdash.org/testSummary.php?project=16name=kdeui-kglobalsettingstestdate=2011-07-27 This commit changes KGlobalSettings' unit test to reflect that change. My first idea was to change the unit test such that it verifies the expected behaviour for both situations, i.e., apps run in a full KDE session and apps run in some other kind of session, but I could not figure out a way to do this without changing the KDE_FULL_SESSION environment variable before the unit test executable is run. In the case that the signal is not expected, I reduced the kWaitForSignal timeout to prevent wasting too much time each time the test is run. Diffs - kdeui/tests/kglobalsettingstest.h 69ed5bf kdeui/tests/kglobalsettingstest.cpp 464825d Diff: http://git.reviewboard.kde.org/r/102098/diff Testing --- The test passes here (run by my kde-devel user in a Konsole inside the regular user's KDE 4.6 session). Thanks, Frank
Re: Formal complaint concerning the use of the name System Settings
On Wed, July 27, 2011 8:33 am, Oswald Buddenhagen wrote: On Tue, Jul 26, 2011 at 11:24:26PM +0200, Ambroz Bizjak wrote: Alternatively, there would be System Settings (KDE desktop configuration) and System Settings (GNOME desktop configuration), possibly the text in parentheses being subscribed instead. This is a little less confusing, but still confusing compared to just System Settings and GNOME System Settings, where System Settings, the native tool, is clearly preferred. i would argue that thomas' solution is better, because it is more explicit. your automatic preference for the desktop's native settings app is counterproductive for the user, because he sees ah, system settings and wtf is this?. he ignores the latter, and is frustrated by the result. in thomas' variant otoh he sees *two* wtf?s, and *has* to research it, understand the underlying problem. this is a requirement of the reality we present him with, so that outcome is *good*. The Ossi solution: the more wtf's the better ;) Seriously, I think you make a good argument - two wtf's are better than one to prompt the user to eventually find the relevant system settings application. In the ideal world, of course, there would be zero wtf's, i.e. the default system settings application would configure all the settings required. Mind you, as Thomas has pointed out, without coordination between translators, Ambroz's scheme could also result in two wtf's in some languages, which rather than being a bad thing, is probably a good thing. (It is impossible to guarantee that all translations will be coordinated - sending an email round translators might help to fix things at the time, but what about future translations (e.g. for new languages) - how could you ensure that they would also be coordinated?) -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Problem with QWidget-mapToGlobal()
On 26/07/2011 22:55, Shaun Reich wrote: I have the same problem with master and Qt 4.7. Clicking the windeco icon on a window which is on either screen results in the menu displaying as far left on the left screen, and the top of the screen + (heightOfTitlebar) it seems. Simply right-clicking the titlebar itself results in an incorrect offset (resulting in it being on the left-most screen at the top. The difference is that the first one is statically always at left-top. The second case (sort of) follows the x axis of the titlebar, but at the top. Anyways, ran it through gdb just for curiousity's sake and yeah mapToGlobal isn't giving what one might expect. Does the widget need a parent or something? Because other uses of it seem pretty similar to this one, yet they work fine. or is this some qt/x bug? It has also been noticed here: http://developer.qt.nokia.com/forums/viewthread/7980/ where the reporter seems to think that (on embedded at least) there was a byte-pixel conversion missing in some cases. Sean -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: [Bug 252817] KWin crashes on intel/mesa glClear(GL_COLOR_BUFFER_BIT)
Am Wed, 27 Jul 2011 16:27:41 + schrieb Martin Gräßlin mgraess...@kde.org: 16:27:38 --- Once again: it is completely pointless of adding further - https://bugs.kde.org/show_bug.cgi?id=278636 Gruß, Thomas
X11 mouse buttons in qt4, qt5, and KDE: please, PLEASE review this design.
This is inspired by Todd RME's post in Vol 99, Issue 83. Todd's post in
kde-core-devel refers to the original bug number, QTBUG-16092, but that
bug is so riddled with unworkable baggage that I cloned another. The
real work will be in QTBUG-19238. QTBUG-19238 currently contains
start-up work on defining the 3 remaining bits in the //Qt::MouseButton
enumeration byte as actual button numbers.
Blind-siding qt Devs on IRC, with no actual document to look at, led to
the unworkable code of QTBUG-19238. (We fell into a frenzy of incorrect
'Rah, rah, YES WE CAN group-think with each other.) And
bugreports.at.nokia.com is fine for reporting bugs, and submitting code,
but I've never received a response to my requests for design
hints/review before starting to write code. (I got nothing from Devnet,
either.) I'm unable to even get a tentative estimate for the API changes
cutoff date on Qt 4.8.
And so, I'm asking for a design review on these two lists. My idea might
not be quite right, let's get it in order BEFORE I start writing code! I
know that this isn't the right place for such a Design Review, but qt
appears to offers no viable alternative. Please feel free to ignore this
entire post if the particular details of my design aren't of interest to
you.
- - - - -
We have 3 bits available for enumeration of additional buttons without
breaking compatibility. I think that the key to getting all 31 possible
X11 buttons into qt is this: Use only two of them, for the buttons sent
up from X11 as Button10 and Button11. (Those are the raw numbers from
X11, in which the four wheel-scroll buttons DID appear as button
numbers.) Then, instead of using the last bit (x80) to define
Button12, give it a name (e.g., Qt::HigherButton) which indicates that
the Button number (from X11, or another platform interface with good
button support) is GREATER than the one that which I've tentatively
enumerating as Button11. BTW, here's the entire enum which I propose
to use:
enum MouseButton {
NoButton = 0x,
LeftButton = 0x0001,
RightButton = 0x0002,
MidButton= 0x0004, // ### Qt 5: remove me
MiddleButton = MidButton,
XButton1 = 0x0008,
BackButton = XButton1,
XButton2 = 0x0010,
ForwardButton= XButton2,
Button10 = 0x0020,
Button11 = 0x0040,
HigherButton = 0x0080,
MouseButtonMask = 0x00ff
};
Q_DECLARE_FLAGS(MouseButtons, MouseButton)
I tossed in alternate names for 'XButton1' and XButton2', which were
introduced in 4.7): By convention, they are almost universally used as
BACK and FORWARD.
When a User wants to receive MouseButtonPress, MouseButtonRelease, or
MouseButtonDblClick events from higher-numbered buttons, it becomes a
two-step process: First, receive the event, and recognize that the
'HighNumberedButton' value is generic. Then, call a new function which
I'll add into the class:
int QMouseEvent::ButtonNumber () const
which shall return the INTEGER Button number of the most recent
Press/Release/DblClick event. BTW, I feel that this function should also
report the integer values for events which occur with lower-numbered
button values: It would allow programmers to define their Button-based
code blocks by branching on integers. (The alternative is to have one
set of branching control statements built for low-numbered buttons,
using the Enum values; plus another set of branching control statements
built for high-numbered buttons, using Integers. Code like that would
look ugly.)
The whole idea of using an enum which couldn't contain any more buttons
than the miserable XI V1.x Button MASK was a *BAD DESIGN* from the
beginning. Let's support old code without changes, but lets also solve
the problem by making the design correct.
-
I am confused by the plugin design which appears to be present in both
qt4 and qt5. Is the qt5 Wayland plugin really supporting only only
THREE mouse buttons, per the following code from
qt5/qtbase/src/plugins/platforms/wayland/qwaylandinputdevice.cpp?
(a code snippet from gitorious):
void QWaylandInputDevice::inputHandleButton(void *data,
struct wl_input_device *input_device,
uint32_t time, uint32_t button, uint32_t state)
{
Q_UNUSED(input_device);
QWaylandInputDevice *inputDevice = (QWaylandInputDevice *) data;
QWaylandWindow *window = inputDevice-mPointerFocus;
Qt::MouseButton qt_button;
if (window == NULL) {
/* We destroyed the pointer focus surface, but the server
* didn't get the message yet. */
return;
}
switch (button) {
case 272:
qt_button = Qt::LeftButton;
break;
case 273:
qt_button = Qt::RightButton;
break;
case 274:
qt_button = Qt::MiddleButton;
break;
default:
Re: My Plans, Your Plans: Berlin Desktop Summit
On Wednesday, July 27, 2011 15:40:11 Aaron J. Seigo wrote: so .. here are my primary goals: [...] One of my goals is to take steps to make the release team more scalable, and reduce its bus numbers. While we really bring out a lot of release, and nearly all of them in time as planned, I think we need to work on two things: * Make Dirk and me replacable -- we have no plans to stop with release team duties, but since it's such a critical task, and ever getting bigger, we need more people we can fall back onto. * The Git migration wasn't exactly a walk in the park, there was lots of last- minute futzing, not everything was clear and I think we put more work than necessary onto various downstreams by changing layout of our tarballs I think overall we're doing pretty well, just that we can do better here and there. * have an enjoyable time with everyone who shows up :) ...and that. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Review Request: Fix logic with clear-button animation in klineedit (notably at first try) and address bug 268898.
On July 26, 2011, 10:46 p.m., Aleix Pol Gonzalez wrote: kdeui/widgets/klineedit.cpp, line 358 http://git.reviewboard.kde.org/r/102095/diff/1/?file=30032#file30032line358 Wouldn't it be better to put it this way? Just saying... d-clearButton-animateVisible(d-wideEnoughForClear text.length() 0); I think the original is clearer, to be honest. - Nicolas --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102095/#review5129 --- On July 26, 2011, 9:54 p.m., Hugo Pereira Da Costa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102095/ --- (Updated July 26, 2011, 9:54 p.m.) Review request for kdelibs. Summary --- Details: - fixes the somewhat incorrect logic in KLineEditButton::animateVisible - simplifies KLineEdit::updateClearButtonIcon consequently. This addresses bug 268898. http://bugs.kde.org/show_bug.cgi?id=268898 Diffs - kdeui/widgets/klineedit.cpp 8f1c8a4 kdeui/widgets/klineedit_p.h 95016bd Diff: http://git.reviewboard.kde.org/r/102095/diff Testing --- tested with klineedittest found in kdelibs/kdeui/tests, this with and without the patch attached to comment #1 of bug 268898, used to actually trigger the mentionned bug. Also tested with other klineEdit implementation such as Dolphin's location bar. Thanks, Hugo
Re: My Plans, Your Plans: Berlin Desktop Summit
Sebastian Kügler wrote: One of my goals is to take steps to make the release team more scalable, and reduce its bus numbers. Surely you mean increase :) A bus number of 1 means the team has a single point of failure. -- Nicolas
Re: Review Request: Fix logic with clear-button animation in klineedit (notably at first try) and address bug 268898.
On July 26, 2011, 10:46 p.m., Aleix Pol Gonzalez wrote: kdeui/widgets/klineedit.cpp, line 358 http://git.reviewboard.kde.org/r/102095/diff/1/?file=30032#file30032line358 Wouldn't it be better to put it this way? Just saying... d-clearButton-animateVisible(d-wideEnoughForClear text.length() 0); Nicolas Alvarez wrote: I think the original is clearer, to be honest. Hugo Pereira Da Costa wrote: I agree with Nicolas. I have nothing against putting boolean test inside the method call, *in principle*, but I believe it's convenient only if the boolean condition is short enough to write. Other than that, anyone willing to go for a ship it ? It was reported on bug 268898 that the patch actually works, and that no regression has been found so far (which is also my own experience) - Hugo --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102095/#review5129 --- On July 26, 2011, 9:54 p.m., Hugo Pereira Da Costa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102095/ --- (Updated July 26, 2011, 9:54 p.m.) Review request for kdelibs. Summary --- Details: - fixes the somewhat incorrect logic in KLineEditButton::animateVisible - simplifies KLineEdit::updateClearButtonIcon consequently. This addresses bug 268898. http://bugs.kde.org/show_bug.cgi?id=268898 Diffs - kdeui/widgets/klineedit.cpp 8f1c8a4 kdeui/widgets/klineedit_p.h 95016bd Diff: http://git.reviewboard.kde.org/r/102095/diff Testing --- tested with klineedittest found in kdelibs/kdeui/tests, this with and without the patch attached to comment #1 of bug 268898, used to actually trigger the mentionned bug. Also tested with other klineEdit implementation such as Dolphin's location bar. Thanks, Hugo
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Wed, Jul 27, 2011 at 07:44:54AM +0200, Jos Poortvliet wrote: Each desktop team should stop picking such generic names. gnome-terminal is fine, so is Konsole. Terminal should probably be renamed. NetworkManager is a braindead name, System Settings implies far more than it accomplishes (it can't handle much 'system settings') so it doesn't seem very smart either. gnome-terminal is called gnome-terminal. Just not in the menu. In the menu we give it an understandable name and limit it to GNOME only. This is not going to change. The debate about things like baobab or 'Disk Usage Analyzer' was held within GNOME a long time ago. There was a general consensus that we don't want to show the actual name except in Help-About. Everything else (menu, window title, etc) uses something which is understandable. Meaning 'Disk Usage Analyzer' and 'Terminal'. Shaun's proposal is a work-around which would probably be 'good enough' but the root cause is that all DE teams try to create their own little world, going LALALA I DON'T SEE YOU about the rest of the world. Care is taken not to cause confusion when using another desktop (NotShowIn + OnlyShowIn). For things part of GNOME Core, we will keep on using understandable names. I can understand that some people want to have a mix and match of e.g. core applications. They're free to do so and nothing is done to prevent that (though it might take a small amount of effort). Further I can also understand that some people prefer so see gnome-terminal and konsole in the menu. However, that is not our goal. We want something simple. For everything part of GNOME Core we have say what it does instead of putting the git module name in the menu. For gnome-control-center specifically, it should pretty much configure everything in the OS. Same for the KDE one. Furthermore, working together on ensuring things are handled in a consistent way across all desktops is something that we has been worked upon by various people across various desktops for many years. Probably some things can/could've been done better, but let's just continue working together. For menu entries: we'll keep using 'Terminal', 'Disk Usage Analyser', etc (+NotShowIn/OnlyShowIn of course). -- Regards, Olav (speaking as a release-team member)
Re: Trouble with udisks-daemon caused by solid
On Wednesday 27 July 2011 17:04:37 Andreas Roth wrote: On 2011-07-27 10:34, Kevin Ottens wrote: On Tuesday 26 July 2011 19:48:06 Andreas Roth wrote: With the help of the amarok developers is found the piece of code, which triggers this issue. In amarok/src/MediaDeviceCache.cpp, function MediaDeviceCache::slotTimeout() calls Solid::Device::listFromType, which does some dbus/udisks magic and this causes the trouble. I haven't gone into the solid code to check what might be wrong there. Well, I guess the real question is why does Amarok poll in the first place? libsolid is doing what it's supposed to do: if you query a list is asks the system for it (in that case udisks). So obviously if you constantly ask the system you get the system component always eating CPU. I don't know, but this you have to ask the amarok developers. But one problem still remains: udisks-daemon complains about a invalid command/messages. It returns the error //org.freedesktop.DBus.Error.UnknownMethod:///Method \GetAll\ with signature \\ on interface//\org.freedesktop.DBus.Properties\ doesn't exist Any ideas on this one? OK, that is more problematic now. Forwarding to the relevant list. Thanks. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
