Problem with QWidget-mapToGlobal()
Hi
If i open the window menu (alt+f3) with the mouse the window shows up in the
top left corner of my screen. The reason is that the following code from
workspace/kwin/libkdecorations/kcommondecoration.cpp line 706
QRect menuRect = m_button[MenuButton]-rect();
QPoint menutop = m_button[MenuButton]-mapToGlobal(menuRect.topLeft());
QPoint menubottom = m_button[MenuButton]-
mapToGlobal(menuRect.bottomRight()) + QPoint(0, 2);
KDecorationFactory* f = factory();
showWindowMenu(QRect(menutop, menubottom));
The mapToGlobal() call is supposed to map the coordinates to screen
coordinates as far i can see. But it does not do that. It always returns some
small values like
(gdb) p menubottom
$2 = {xp = 23, yp = 24}
I could even say always those values because it looks like the menu is always
on the same spot.
I have a two screen setup here. That could be related.
Any ideas what is wrong here?
Mike
Re: Formal complaint concerning the use of the name System Settings
On Tue, Jul 26, 2011 at 12:53 AM, Ambroz Bizjak ambr...@gmail.com wrote: Hi Mark, The localization stuff you're concerned about is happening below the desktop file layer (in KDE's case, kconfigdata.h), and should work automatically, i.e. if you ask for some key it will automatically give you a localized version if available. Also, DE-specific desktop file keys would be a good thing to have in general, so I hope people do not oppose the idea just because it's not the ideal solution to this particular problem. Besides, it's (I think) very easy to implement, so even if we don't manage to push it, it wouldn't be that much time lost :) . I've done many enhancements to open-source projects, and many of them weren't liked by the developers - but I still think I did the right thing, and I'm not afraid of contributing for the fear of being opposed. Regards, Ambroz On Tue, Jul 26, 2011 at 12:19 AM, Mark mark...@gmail.com wrote: On Mon, Jul 25, 2011 at 9:51 PM, Ambroz Bizjak ambr...@gmail.com wrote: Hi Mark, I've done some small research on what components would have to be updated for the desktop-specific-names solution. I think that would be: - The Desktop Entry Specification, http://standards.freedesktop.org/desktop-entry-spec/latest/ - KDE's KDesktopFile, https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/changes/kdecore/config/kdesktopfile.cpp - Xfce's libxfce4menu, in particular http://git.xfce.org/xfce/libxfce4menu/tree/libxfce4menu/xfce-menu-item.c - Gnome's libgnome-menu, in particular http://svn.gnome.org/viewvc/gnome-menus/trunk/libmenu/desktop-entries.c Regards, Ambroz Hi, Thanx for the list. I already found the spec and kde file. One thing i can't find though is the part that makes multilanguage stuff for desktop files working.. Those 3 source files all just grab the Name value but where does it do the magic that happens when i set my language to dutch.. then it grabs Name[nl] but where does it do that? Asking that since the properties i proposed should have multi language suppert as well.. And besides that.. I do want to implement it, but i'm getting the feeling there isn't that much support for it thus wasting my time if i implement it since it won't get accepted anyway. (which i rather avoid). It's just a feeling and i hope i'm wrong... Regards, Mark You are completely right. However one small question.. In KDE you have a readName function that reads the Name value from the desktop file. But how should that behave if a desktop file has the following and is read from a KDE environment: NativeDE=Gnome NameNonNative=Gnome System Settings Would the readName property then return the NameNonNative value if it's read from a KDE environment..? That would seem the most easy solution but a bit dirty as well -- only seems nice if the spec would specifically say that the Name property is overwritten by NameNonNative if the NativeDE property is set and different from the currently used DE.
Re: Formal complaint concerning the use of the name System Settings by GNOME
[: Mark :] Just a small suggestion on how i think this should be fixed (since 2 desktop files for one app seems just ugly to me). Perhaps it's better to extend the desktop file specification: [...] Name=System Settings NativeDE=KDE NameNonNative=KDE System Settings Adding new field into .desktop specification would have a ripple effect. You have already felt that with KDesktopFile::readName(), and it would also be necessary to update localization systems, several of which are in use. This means that a new field should be added to .desktop specification only when it is obvious that it serves a general and permanent purpose. This purpose is not such. As for double .desktop files, I think that the ugliness of the solution matches well the stupidity of the problem. -- Chusslove Illich (Часлав Илић) signature.asc Description: This is a digitally signed message part.
Re: Formal complaint concerning the use of the name System Settings by GNOME
On 07/25/2011 04:53 PM, Aaron J. Seigo wrote: On Monday, July 25, 2011 12:19:19 Andrea Diamantini wrote: KCMsshould live in kde-runtime. Isn't it? they do. So, it's just my bad luck the ones I use (cookies, proxy, cache) are not. Working for a solution... -- Andrea Diamantini, adjam GPG Fingerprint: 57DE 8E32 7D1A 0E16 AA52 59D8 84F9 3ECD DBF9 730F rekonq project WEB: http://rekonq.kde.org IRC: rekonq@freenode
Re: Formal complaint concerning the use of the name System Settings by GNOME
Le 25/07/2011 19:51, Lennart Poettering a écrit : On Mon, 25.07.11 17:40, Giovanni Campagna (scampa.giova...@gmail.com) wrote: The spec does not provide a list of shared keys, does such a list exist? If there is no such list I don't see how we could share anything. http://wiki.freedesktop.org/wiki/Specifications/XSettingsRegistry This isn't really up-to-date as it appears. These are the settings that Gtk currently knows: http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdksettings.c#n37 Thanks for the pointers. The IconThemeName in particular will be quite useful for me. Aurélien
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Mon, July 25, 2011 8:08 pm, Nicolas Alvarez wrote: David Jarvie wrote: On Mon, July 25, 2011 12:50 pm, Ambroz Bizjak wrote: Hi Mark, have you seen my proposed improvement on your suggestion? http://lists.kde.org/?l=kde-core-develm=131149560119520w=2 I suggest that you consider it, because it would avoid having to update the Freedesktop specification and any DE that doesn't name its programs differently in other DEs (e.g. Xfce). This proposal has the same drawbacks as Mark's - it is aimed at knowledgeable users, not the ordinary user who may not be aware of which desktop a particular application is from. See http://lists.kde.org/?l=kde-core-develm=131159889604990w=2. So what is *your* proposed solution? As you say, the long term solution is to have setting interoperability. The key words there are long term. We can't do that *now*, before the new KDE release and before the new GNOME release. We need a solution *now* to avoid having two entries with the exact same name in the application list. Mark and Ambroz's solutions have the advantage of not requiring months of collaboration and programming, which would be needed for setting interoperability. I don't object to Mark's proposal as a short term solution - it's better than having two identically named applications. I'm just concerned that it isn't ideal from the ordinary user's perspective, and that it should be recognised as being an interim fix. The longer term aim should of course be to share as many as possible of the settings between desktops and therefore make them accessible from both Gnome and KDE System Settings applications. KCMs should be categorised according to whether or not they contain settings which are not shared between desktops, and applications using unshared settings should as a matter of policy be expected to provide direct access to the relevant KCMs, thus avoiding the need for the user to find and run the 'other' System Settings. -- David Jarvie. KDE developer. KAlarm author - http://www.astrojar.org.uk/kalarm
Re: Problem with QWidget-mapToGlobal()
On Tuesday 26 July 2011 09:34:57 Michael Jansen wrote: The mapToGlobal() call is supposed to map the coordinates to screen coordinates as far i can see. But it does not do that. It always returns some small values like We've seen this fail in Kontact mobile in situations where the widget was embedded in a graphicsview, directly or indirectly. Could be totally unrelated, of course, just thought I'd mention it. Fixed in Qt, I believe, back then. Till
Re: Formal complaint concerning the use of the name System Settings by GNOME
Il giorno lun, 25/07/2011 alle 12.56 +0200, Markus Slopianka ha scritto: Which settings don't they follow? Apart from theme (as there is no gtk3 engine written in Qt yet) Why do theme engines have to be written for Qt in order to let GTK apps at least integrate visually into a Qt environment. There should be a Qt theme loader in GTK just as there is a GTK theme loader in Qt. Well, I think that an hypothetical KDE-looking GTK theme would use Qt calls to paint widget, same as the GNOME-looking Qt theme paints using gtk_paint_*. Well, other than that: GNOME/GTK apps don't integrate with the Notifications panel, File Type Associations, Icon theme, CDDB config (for media players or CD rippers), ... Gtk apps normally use either libnotify, libappindicator or GtkStatusIcon (systray protocol). All of them are supported by KDE, AFAIK. File type associations are from xdg-mime/shared-mime-info, and should be shared by all freedesktop toolkits. Icon theme is taken from XSettings, you just need to export it, like Xfce and Lxde do. As for CDDB config, I don't think GNOME as something shared across the desktop for that. Giovanni signature.asc Description: This is a digitally signed message part
Re: Formal complaint concerning the use of the name System Settings
(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 the result of which would be that there would be specific (possibly different) names for KDE, Gnome and Xfce, and a default name for other DEs. The same is not achievable with your suggestion. I suppose it would be possible to achieve this without embedding any value in the key itself, but it would become harder to read and to implement. For example, the following: Name=Some Generic Name Specific-Name-Count=3 Specific-Name-Desktop0=KDE Specific-Name-Value0=Name in KDE only Specific-Name-Desktop1=GNOME Specific-Name-Value1=Name in GNOME only Specific-Name-Desktop2=XFCE Specific-Name-Value2=Name in XFCE only which I think is flawed compared to the above version. It's hard to read and to modify, harder to implement, and introduces unnecessary coupling between the fields. What do you think? Regards, Ambroz On Tue, Jul 26, 2011 at 1:19 PM, Mark mark...@gmail.com wrote: On Tue, Jul 26, 2011 at 11:48 AM, Ambroz Bizjak ambr...@gmail.com wrote: Hi Mark, I am strongly opposed to the particular solution you are implementing. You are trying to extend the desktop file specification in a very non-generic and non-intuitive way, and people will obviously oppose that. The particular problems I see with your original proposed solution are: - You are only extending the Name field. It will not be possible to have a DE-specific GenericName field, for example. - You are adding two new fields to the specification, when the same effect could be achieved with just one new field (or class of fields) - Anything that is not aware of the your extension (which probably means it is not KDE) will be using the KDE-specific name rather than the generic name, until that software was patched to understand the extension. Please consider my second suggestion - it is a much more generic solution, and it does not have any of the problems I listed above. http://lists.kde.org/?l=kde-core-develm=131160689716557w=2 I'm sorry, I messed up the example there; it should say: Name=KDE System Settings Specific-KDE-Name=System Settings To implement this solution I guess you'd have to modify KConfigGroup::readEntry to first look for Specific-KDE-name and revert to name if the former does not exist. Regards, Ambroz On Tue, Jul 26, 2011 at 9:54 AM, Mark mark...@gmail.com wrote: On Tue, Jul 26, 2011 at 12:53 AM, Ambroz Bizjak ambr...@gmail.com wrote: Hi Mark, The localization stuff you're concerned about is happening below the desktop file layer (in KDE's case, kconfigdata.h), and should work automatically, i.e. if you ask for some key it will automatically give you a localized version if available. Also, DE-specific desktop file keys would be a good thing to have in general, so I hope people do not oppose the idea just because it's not the ideal solution to this particular problem. Besides, it's (I think) very easy to implement, so even if we don't manage to push it, it wouldn't be that much time lost :) . I've done many enhancements to open-source projects, and many of them weren't liked by the developers - but I still think I did the right thing, and I'm not afraid of contributing for the fear of being opposed. Regards, Ambroz On Tue, Jul 26, 2011 at 12:19 AM, Mark mark...@gmail.com wrote: On Mon, Jul 25, 2011 at 9:51 PM, Ambroz Bizjak ambr...@gmail.com wrote: Hi Mark, I've done some small research on what components would have to be updated for the desktop-specific-names solution. I think that would be: - The Desktop Entry Specification, http://standards.freedesktop.org/desktop-entry-spec/latest/ - KDE's KDesktopFile, https://projects.kde.org/projects/kde/kdelibs/repository/revisions/master/changes/kdecore/config/kdesktopfile.cpp - Xfce's libxfce4menu, in particular http://git.xfce.org/xfce/libxfce4menu/tree/libxfce4menu/xfce-menu-item.c - Gnome's libgnome-menu, in particular http://svn.gnome.org/viewvc/gnome-menus/trunk/libmenu/desktop-entries.c Regards, Ambroz Hi, Thanx for the list. I already found the spec and kde file. One thing i can't find though is the part that makes multilanguage stuff for desktop files working.. Those 3 source files all just grab the Name value but where does it do the magic that happens when i set my language to dutch.. then it grabs Name[nl] but where does it do that? Asking that since the properties i proposed should have multi language suppert as well.. And besides that.. I do want to implement it, but i'm getting the feeling there isn't that much support for it thus wasting my
Re: Formal complaint concerning the use of the name System Settings
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
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 way - systemsetting would eg. require an KDE System Settings entry for _every_ desktop but KDE (and the no desktop variant, just like the gnome variant required Gnome System Settings for every desktop but GNOME to prevent clashes) what could the ppl. you want to put this load onto (not me ;-) call it actually inferior to Mark's solution - which can not detect and effectively avoid clashes for sure but at least scales much better. Thomas
Re: X11 expert help needed
On Monday 18 July 2011, Alexander Neundorf wrote: Hi, I'm currently comparing our FindX11.cmake with the one in current cmake. Our copy is in kdelibs/cmake/modules/, CMake's is in its Module/ directory. There are some things our version checks for, which the one from cmake doesn't, and vice versa. Also, we append more of the libs to the X11_LIBRARIES variable. Is this good ? Should the stuff we do just be merged into the cmake version ? Can somebody who knows more about X11 please have a look at these two files, one in kdelibs, the other one in cmake 2.8.5 or git HEAD ? http://cmake.org/gitweb?p=cmake.git;a=summary Helping hands are very appreciated :-) Alex Anybody ? Alex
Re: X11 expert help needed
On Tuesday 26 July 2011 22.43.33 Alexander Neundorf wrote: Should the stuff we do just be merged into the cmake version ? Can somebody who knows more about X11 please have a look at these two files, one in kdelibs, the other one in cmake 2.8.5 or git HEAD ? http://cmake.org/gitweb?p=cmake.git;a=summary What happens if you use de cmake version (copy over kde version then try a cmake... How much extra does de KDE version do and is it possible to do that in a sort of X11ExtraCheck cmake? R
Re: X11 expert help needed
On Tuesday 26 July 2011, Ruurd Pels wrote: On Tuesday 26 July 2011 22.43.33 Alexander Neundorf wrote: Should the stuff we do just be merged into the cmake version ? Can somebody who knows more about X11 please have a look at these two files, one in kdelibs, the other one in cmake 2.8.5 or git HEAD ? http://cmake.org/gitweb?p=cmake.git;a=summary What happens if you use de cmake version (copy over kde version then try a cmake... How much extra does de KDE version do and is it possible to do that in a sort of X11ExtraCheck cmake? No need to copy and try... a diff shows the differences. It's checking for a few things more here and there. I could simply add that to the cmake version. But since I actually don't really know what these libs are for, whether they are always there or only in some versions or on some OSs, or whatever, I'd like to get some expert input on that. Alex
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Tue, Jul 26, 2011 at 01:26:03PM +0200, Mark Gaiser wrote: In my opinion there should be a cross desktop system settings application where the KDE implementation can use KCM and the gnome implementation uses whatever they want to use. That would be the ideal solution imho. you mean, like two date time settings applets inside the same shell application? ;)
Re: Formal complaint concerning the use of the name System Settings by GNOME
On Tue, Jul 26, 2011 at 11:09 PM, Oswald Buddenhagen o...@kde.org wrote: On Tue, Jul 26, 2011 at 01:26:03PM +0200, Mark Gaiser wrote: In my opinion there should be a cross desktop system settings application where the KDE implementation can use KCM and the gnome implementation uses whatever they want to use. That would be the ideal solution imho. you mean, like two date time settings applets inside the same shell application? ;) wahahaha no, since that would mean the settings are not only stored in one app, but also shown in one place.. My idea is to have them stored in one central place so that each app can access it without the need of pulling in an entire desktop just for a setting. A nice side effect then is that it becomes possible to implement a cross desktop system settings where you would still have a desktop category first before you get all the settings. Kinda hard to explain..
Re: Job available: medical device company
On Tuesday 19 July 2011 16:01:06 Stefan Majewsky wrote: On Mon, Jul 18, 2011 at 6:22 PM, David nonot...@gmail.com wrote: (rational: There is no kde-jobs list yet.) @sysadmin: Could you create one? Greetings Stefan Given the very low volume I don't think that is necessary, a qt-jobs list hosted by Qt would be a better option. That said, I reckon kde-devel is a better list than kde-core-devel to email job offers to, it has wider coverage. John.
Re: Problem with QWidget-mapToGlobal()
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? -- Shaun Reich, KDE Software Developer (kde.org)
