Re: Equivalent of KDE::version*()?
On Monday 15 June 2015 22:23:17 Jaroslaw Staniek wrote: > Hi, > One would need a need runtime version information of particular kf5 > libraries -- in addition to version with which the software has been > built. > > It seems that mostly Plasma and KActivities have equivalent of runtime > version information. > I am not looking build-time *_version.h files generated (with > *_VERSION_* macros) but something like > plasma-framework/src/plasma/version.h. > > Attica is a good exception here, I cannot spot anything else. > > PS: Maybe the code can be generated? What would this be useful for? Working around bugs? My plan was rather not to have bugs in the first place :-) Yeah yeah, I know ;) If there's usefulness in this, we could generate some code indeed (ECM to the rescue once more...). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125237: Change KKeyserver (x11) to categorized logging
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125237/ --- (Updated Sept. 29, 2015, 7:34 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Changes --- Submitted with commit 9a0431fc5a275ced2e410f8e815c9fd07685d715 by Martin Gräßlin to branch master. Repository: kwindowsystem Description --- Introduces a dedicated logging category for the kkeyserver. Diffs - src/debug_p.h cb3c5492ef416385eb774c13308f654b0a71a350 src/debug_p.cpp 4a1dd75786cd18c54c24abf5908c515ed6123ce2 src/platforms/xcb/kkeyserver.cpp 6cfaa8962f6873fa8d34441b6b784eca4ba9b776 Diff: https://git.reviewboard.kde.org/r/125237/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125238: [xcb] Consider mods in KKeyServer as initialized on platform != x11
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125238/ --- (Updated Sept. 29, 2015, 7:34 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Changes --- Submitted with commit 4b9317af68bd1758dd2675d8e8386d674c927945 by Martin Gräßlin to branch master. Repository: kwindowsystem Description --- Calling initializeMods again won't change anything, just print a warning each time. Let's consider them as initialized on non x11 platform after first try. Diffs - src/platforms/xcb/kkeyserver.cpp 6cfaa8962f6873fa8d34441b6b784eca4ba9b776 Diff: https://git.reviewboard.kde.org/r/125238/diff/ Testing --- Significant less warnings when using kwin_wayland. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120228: Support Gerrit in the fancy header style
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120228/ --- (Updated Sept. 29, 2015, 9:34 a.m.) Status -- This change has been discarded. Review request for KDE Frameworks and KDEPIM. Repository: kdepim Description --- If the email is from Gerrit the following information is added to the header: * message type * url to change * change-id as link test for the url I'm not sure which is the right branch for such a change to go in. Diffs - messageviewer/header/fancyheaderstyle.cpp f58f07bda9b750aed30795644bdba5175f5edd56 messageviewer/header/headerstrategy_p.h 14951ea792ee13e468ff5a047c13dc94b78d6bc2 Diff: https://git.reviewboard.kde.org/r/120228/diff/ Testing --- File Attachments Example for a new change https://git.reviewboard.kde.org/media/uploaded/files/2014/09/16/60cdd1c0-d911-49a7-b184-cbb424d45ae1__gerrit-fancy-.png Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125309: Support multiple X servers in the NETWM classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125309/#review86093 --- Ship it! Ship It! - Martin Gräßlin On Sept. 28, 2015, 5:45 p.m., Thomas Lübking wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125309/ > --- > > (Updated Sept. 28, 2015, 5:45 p.m.) > > > Review request for KDE Frameworks and Martin Gräßlin. > > > Repository: kwindowsystem > > > Description > --- > > alteration review #125259 minus the autotests > > Significant difference is the creation and handling of the Atom enum. > > 1. Net::Utf8 makes no sense > 2. Net::WmFoo re/adds ambiguity between _NET_WM and WM_, notably on _STATE > (there's nothing such as XA_WM_STATE) > 3. the most "important" grouping is whether it's WM_, NET_WM_, NET_, > KDE_NET_, or ... UTF8, I'm not sure why one would add more enums (since this > is internal API and the resolved type will always be xcb_atom_t - in worst > case we run into errors on comparing the enums > 4. I wanted to get rid of the explicit counter variable as well as any loose > assignment between atom variable/enum and string. > > - > > So far on first creation of a NETRootInfo or NETWinInfo a static > initialization of atoms was performed. This meant that the NET classes > are only able to interact with the X server the first NET class is > connected to. > > Normally applications don't need to interact with multiple X servers. > An exception is kwin_wayland which needs a connection to its Xwayland > server and on the x11 backend to the X server it renders to. So far > KWin could not use the NET classes for it, causing the rendering window > to e.g. not have a window title. > > This change removes the implicit constraint on one X server by > creating a hash of connection and atoms. For each created NET class > we check whether we have already resolved the atoms, if yes we reuse > otherwise we create them. > > For the normal use case of one X11 connection the change should be > rather minimal. Instead of performing the check whether the static > atoms have been created, it now is a check whether the atoms for the > connection have been created. The atoms are kept in a > QSharedDataPointer ensuring that we don't needless copy the atoms into > each class. > > CHANGELOG: Allow interacting with multiple X servers in the NETWM classes. > > > Diffs > - > > src/platforms/xcb/atoms_p.h PRE-CREATION > src/platforms/xcb/netwm.cpp d99a925 > src/platforms/xcb/netwm_p.h 917a86e > > Diff: https://git.reviewboard.kde.org/r/125309/diff/ > > > Testing > --- > > > Thanks, > > Thomas Lübking > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets
On Friday 25 September 2015 14:09:14 René J.V. Bertin wrote:
> Also, it strikes me as bit of a gamble not to have implemented a framework
> for dealing with what one might call Freedesktop or XDG compliance, but to
> have left that to QStandardPaths, basically. It must have been clear from the
> onset that QSP complies with Freedesktop/XDG conventions only in standard
> Unix/Linux Qt builds (OS X being a "deviant" Unix configuration).
Yes that was clear and on purpose.
The intent was not to use XDG-like directories on all platforms, but rather to
"do what the platform recommends/forces us to do" - which is QSP.
You don't *really* need XDG on OSX. You need files to be found, it's just
easier to do that by coying what we do on Linux/BSD ;)
> I guess that outlines another possible solution: create a framework that can
> provide the required glue on platforms where this might be required or
> desired, with build switches to control optional behaviour *and* ensure that
> all applications still end up using the same conventions.
That is KStandardDirs, and I certainly do NOT want to bring that back. It would
go exactly against "all apps use the same conventions"
because apps using QSP and apps using KStandardDirs would do things
differently. And because it assumed XDG layout everywhere,
which looks strange on OSX, looks a lot stranger on Windows, and is just not
allowed on Android or iOS.
> > So OK, kcoreaddons could switch QSP behavior on Mac, provided that
> > it's documented with a huge warning, and that it can be turned off. It
> > breaks
> > the principle of least surprise ("ever since my app started using one tiny
> > unrelated class out of KF5, my users lost all their previous
> > configuration!").
>
> This shouldn't happen when things are done correctly. The choice what
> locations are to be used should be made at a global level and apply for the
> whole installed KF5 environment. That's why I went with a link-time switch
> that gets set immutably when an application is loaded. It's not intended to
> provide things like runtime switchable configuration profiles.
I meant "Version 6 of my Qt app didn't use KF5, version 7 used one widget from
KF5, say KTextEdit, and my users lost
all of their previous configuration because this brought in kcoreaddons, which
toggled a global switch in QSP!!! You guys suck!!!" :-)
> > The advantage of this solution compared to your initial question: no build
> > system hackery
> > (which would break the principle of least surprise even more, I would say).
>
> What I like about a build system modification (esp. at the level of Qt
> component selection) is that it's done in places that aren't likely to evolve
> frequently. And where, if they do, people will be careful. My experience with
> modifying source code (e.g. to make X11 calls conditional) is that not
> everyone is very careful to leave such modifications in place, let alone
> ensure that an upstream change doesn't break them. I won't call it lack of
> respect, but sometimes it feels like that ;)
Hidden magic is good because it's hidden so people won't break it? I can't
agree to this line of argumentation.
Hidden magic is *usually* bad because it fools expectations. And on top of
that, it can still be broken - unknowingly - because it's so hidden.
Anyway, meta discussions won't help, let's dive into specifics again ;)
> > One thing I like about this, as a side effect, is that my unittests which
> > need to
> > have control over *global* QSP paths (which I do by setting XDG_DATA_DIRS
> > but I have to skip such unittests on OSX/Windows) could then be enabled on
> > OSX.
>
> You should also be able to do that with a build system modification that
> leaves a choice, no?
Sure, unittests are easy (self contained), whichever solution we end up with.
> > which means the suggested solution here would break third-party libs
> > which
> > install stuff into default QSP paths, and then we toggle the mode to XDG,
> > and they
> > can't find their stuff anymore...
>
> It'd be the responsibility of packagers to ensure that those 3rd party
> libraries are patched too, or built with the same switch setting...
Hmm. You envision a world where a single packaging system controls all the Qt
based libs.
I suppose this is the case for Macports (and its alternatives like Fink,
assuming people can't
mix-n-match between the two)? Or can an app in Macports link to a lib from the
"real" OSX
(I guess I mean for instance /Library)?
If indeed this is about a self-contained world where all libs and apps should
use the same paths,
then we're back to the easiest solution: a Qt patch for Macports.
Or the equivalent, an upstream Qt change which is enabled when configuring Qt
for Macports.
If however this is about a mix-and-match world where some libs install files
into XDG-like paths
and some other libs install files into OSX-like paths, and some apps link to
both of these libs,
then
Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets
On Tuesday September 29 2015 09:45:02 David Faure wrote: Hi, I appreciate your continued interest (and not having to send a 'bump' message :)) >You don't *really* need XDG on OSX. You need files to be found, it's just >easier to do that by coying what we do on Linux/BSD ;) Sure. But if it wasn't clear: for use in frameworks (sic..) like those provided by MacPorts those files have to be found in locations where non-Qt code will also find them. Which probably leaves little choice ... BTW, was that an intentional slip-up, coy instead of copy? ;) Question is, what would be the real MacCoy? :) >That is KStandardDirs, and I certainly do NOT want to bring that back. It >would go exactly against "all apps use the same conventions" I would say that it helps impose that "all apps use the same conventions", at least that's how I'd implement it. >because apps using QSP and apps using KStandardDirs would do things >differently. I'm not suggesting to bring back KSD, much as having a patchable proxy class would make things easy as they were with KDE4. I'm really only thinking of something that provides a hook to modify QSP behaviour in a controlled fashion for *all* applications that belong to the class where the native QSP behaviour is not appropriate. >And because it assumed XDG layout everywhere, >which looks strange on OSX, looks a lot stranger on Windows, and is just not >allowed on Android or iOS. FWIW, I don't see why KSD could not have been rewritten to behave more appropriately? >I meant "Version 6 of my Qt app didn't use KF5, version 7 used one widget from >KF5, say KTextEdit, and my users lost >all of their previous configuration because this brought in kcoreaddons, which >toggled a global switch in QSP!!! You guys suck!!!" :-) To which you could reply "but you asked for it by configuring your KF5 build to modify Qt's behaviour". Not changing stock behaviour by default has clearly always been a requirement for me. >Hidden magic is good because it's hidden so people won't break it? I can't >agree to this line of argumentation. Didn't say it's good, and also didn't intend to hide through obfuscation. Rather, hide in plain sight, with a good ample description that would be a bit cumbersome in "user source code". But, >Anyway, meta discussions won't help, let's dive into specifics again ;) >Hmm. You envision a world where a single packaging system controls all the Qt >based libs. Indeed, but I don't envision that as the only or even the centre of the universe. It just happens to be the world I live on ;) >I suppose this is the case for Macports (and its alternatives like Fink, >assuming people can't >mix-n-match between the two)? Or can an app in Macports link to a lib from the >"real" OSX >(I guess I mean for instance /Library)? MacPorts, HomeBrew and (AFAIK) Fink are comparable to things like Gentoo Prefix in that they attempt to be as self-contained as possible. It's not even their goal to provide libraries and middleware for use in whatever personal or professional projects users might have. They exist with the goal to make it easy to install (free) software, and strive for reproducible builds (which explains the goal of being self-contained). The only outside/system libraries that apps in MacPorts are supposed to link to are the system SDKs and a select few other libraries which would otherwise lead to circular dependencies. You can have MacPorts and Fink installed alongside each other (for users who know what they're doing); HomeBrew installs stuff into /usr/local and is thus more or less incompatible with anything else. MacPorts also has the guideline to force applications and libraries to build against MacPorts dependencies instead of against any "embedded" copies of those libraries that might be shipped with the code. I'm even tempted to say that Qt is provided only so that Qt applications can all be built against the same, controlled version. Or at least that that argument is at least as important as the reduction of the disk footprint. And yes, MacPorts uses a build and packaging system written in Tcl (running in a special tclsh); Fink uses Debian's packaging system and HomeBrew uses "recipes" written in Ruby . So all have ways to distribute specific patches (like my QSP patch, currently) and perform all kinds of magic . Which also means that it's perfectly possible to implement some or all of the changes we're discussing here in the appropriate MacPorts ports. That doesn't take away the fact that I need some guidance on how best to implement those changes ... and there is a MacPorts guideline that they shouldn't be the repository for upstream patches. >If indeed this is about a self-contained world where all libs and apps should >use the same paths, >then we're back to the easiest solution: a Qt patch for Macports. >Or the equivalent, an upstream Qt change which is enabled when configuring Qt >for Macports. Yes and no. Yes, the
Re: Review Request 125390: Fix build on Mac OS X
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125390/ --- (Updated Sept. 29, 2015, 1:10 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Alex Merry. Changes --- Submitted with commit 0f8592f27064ba92485928a0de074c58118414aa by Harald Fernengel to branch master. Repository: kdesignerplugin Description --- Qt 5.5 requires Qt5UiPlugin framework to be in the include path. On Linux this didn't break as all Qt headers are typically in the same prefix, but on Mac, the include hierarchy is quite different. Diffs - KF5DesignerPluginMacros.cmake 15db23db3c275c231487d8bafc8fb3f4df624905 Diff: https://git.reviewboard.kde.org/r/125390/diff/ Testing --- Thanks, Harald Fernengel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets
On Tuesday September 29 2015 09:45:02 David Faure wrote: >> > One thing I like about this, as a side effect, is that my unittests which >> > need to >> > have control over *global* QSP paths (which I do by setting XDG_DATA_DIRS >> > but I have to skip such unittests on OSX/Windows) could then be enabled on >> > OSX. >I would just like to take one step back and make sure this is going into a >direction that makes sense. >Let's assume you can toggle QSP behavior to XDG somehow (per call or globally >or whatever). >What then? Macports users will have to set XDG_* env vars for the apps to >work? I thought >setting env vars wasn't an option? Just so everyone has a clear view of what locations we're talking about: >>> stock QStandardPaths from Qt 5.5.0 on OS X (from qtdiag from my >>> port:qt5-kde; these only have a fix applied to the FontsLocation) Standard paths [*...* denote writable entry]: DesktopLocation: "Desktop" */Users/bertin/Desktop* DocumentsLocation: "Documents" */Users/bertin/Documents* FontsLocation: "Fonts" */Users/bertin/Library/Fonts* /Library/Fonts /System/Library/Fonts ApplicationsLocation: "Applications" */Applications* MusicLocation: "Music" */Users/bertin/Music* MoviesLocation: "Movies" */Users/bertin/Movies* PicturesLocation: "Pictures" */Users/bertin/Pictures* TempLocation: "TemporaryItems" */var/folders/j1/blabla/T* HomeLocation: "Home" */Users/bertin* AppLocalDataLocation: "Application Support" */Users/bertin/Library/Application Support/QtProject/qtdiag* /Library/Application Support/QtProject/qtdiag /opt/local/libexec/qt5/bin/ CacheLocation: "Caches" */Users/bertin/Library/Caches/QtProject/qtdiag* /Library/Caches/QtProject/qtdiag GenericDataLocation: "Application Support" */Users/bertin/Library/Application Support* /Library/Application Support RuntimeLocation: "Application Support" */Users/bertin/Library/Application Support* ConfigLocation: "Preferences" */Users/bertin/Library/Preferences* DownloadLocation: "Desktop" */Users/bertin/Downloads* GenericCacheLocation: "Caches" */Users/bertin/Library/Caches* /Library/Caches GenericConfigLocation: "Preferences" */Users/bertin/Library/Preferences* AppDataLocation: "Application Support" */Users/bertin/Library/Application Support/QtProject/qtdiag* /Library/Application Support/QtProject/qtdiag /opt/local/libexec/qt5/bin/ AppConfigLocation: "Preferences" */Users/bertin/Library/Preferences/QtProject/qtdiag* >>> stock QStandardPaths from Qt 5.5.0 on Linux; also note the xdg-kde-plasma >>> directories that don't show up in the OS X locations: Standard paths [*...* denote writable entry]: DesktopLocation: "Desktop" */home/bertin/Desktop* DocumentsLocation: "Documents" */home/bertin/Documents* FontsLocation: "Fonts" */home/bertin/.fonts* ApplicationsLocation: "Applications" */home/bertin/.local/share/applications* /usr/share/applications /usr/share/kde-plasma/applications /usr/local/share/applications MusicLocation: "Music" */home/bertin/Music* MoviesLocation: "Movies" */home/bertin/Videos* PicturesLocation: "Pictures" */home/bertin/Pictures* TempLocation: "Temporary Directory" */tmp* HomeLocation: "Home" */home/bertin* AppLocalDataLocation: "Application Data" */home/bertin/.local/share/QtProject/qtdiag* /usr/share/QtProject/qtdiag /usr/share/kde-plasma/QtProject/qtdiag /usr/local/share/QtProject/qtdiag CacheLocation: "Cache" */home/bertin/.cache/QtProject/qtdiag* GenericDataLocation: "Shared Data" */home/bertin/.local/share* /usr/share /usr/share/kde-plasma /usr/local/share RuntimeLocation: "Runtime" */run/user/UID* ConfigLocation: "Configuration" */home/bertin/.config* /etc/xdg/xdg-kde-plasma /usr/share/upstart/xdg /etc/xdg DownloadLocation: "Download" */home/bertin/Desktop/Downloads* GenericCacheLocation: "Shared Cache" */home/bertin/.cache* GenericConfigLocation: "Shared Configuration" */home/bertin/.config* /etc/xdg/xdg-kde-plasma /usr/share/upstart/xdg /etc/xdg AppDataLocation: "Application Data" */home/bertin/.local/share/QtProject/qtdiag* /usr/share/QtProject/qtdiag /usr/share/kde-plasma/QtProject/qtdiag /usr/local/share/QtProject/qtdiag AppConfigLocation: "Application Configuration" */home/bertin/.config/QtProject/qtdiag* /etc/xdg/xdg-kde-plasma/QtProject/qtdiag /usr/share/upstart/xdg/QtProject/qtdiag /etc/xdg/QtProject/qtdiag On a related note: those Linux locations come from qtdiag of a Qt installed into /opt/local, actually a Linux build of the aforementioned qt5-kde port (MacPorts package). I'm surprised that I'm not seeing /opt/local show up anywhere in there. What would be the consensus to modify in these locations, for a Qt installed into /opt/local where KF5 could also be installed? Replace everything pointing to /usr/local with /opt/local, or also replace /usr with /opt/local? R. ___ Kde-frameworks-devel mailing list
Re: Review Request 125449: Add support for desktop file name to KAboutData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125449/#review86103 --- Ship it! +1, will be needed to have realiable task icons in wayland - Marco Martin On Sept. 29, 2015, 11:53 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125449/ > --- > > (Updated Sept. 29, 2015, 11:53 a.m.) > > > Review request for KDE Frameworks, David Faure and Marco Martin. > > > Repository: kcoreaddons > > > Description > --- > > This change introduces a way to set the new QGuiApplication property > "desktopFileName" through KAboutData. By default it gets constructed > to a combination of reverse domain name and component name. > E.g.: org.kde.kwrite > > In addition a new command line option --desktopfile is added to allow > passing the desktop file name to the application. This is in particular > useful for wrapper applications (such as kpackagelauncherqml) and > applications having in general multiple desktop files. Thus each desktop > file can put it's own name into the exec command. > > > Diffs > - > > autotests/kaboutdatatest.cpp 08690b7abed7727ab5610e41cfb124fc27cd88a5 > src/lib/kaboutdata.h 134819b1ee32d5cf1e4f379b547e52e387dd674e > src/lib/kaboutdata.cpp af10fc60053b294789f2813680299be2bc4b7a64 > > Diff: https://git.reviewboard.kde.org/r/125449/diff/ > > > Testing > --- > > See added unit test. For the command line parser I only tested whether it > gets added to applications. > > > Thanks, > > Martin Gräßlin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 125449: Add support for desktop file name to KAboutData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125449/ --- Review request for KDE Frameworks, David Faure and Marco Martin. Repository: kcoreaddons Description --- This change introduces a way to set the new QGuiApplication property "desktopFileName" through KAboutData. By default it gets constructed to a combination of reverse domain name and component name. E.g.: org.kde.kwrite In addition a new command line option --desktopfile is added to allow passing the desktop file name to the application. This is in particular useful for wrapper applications (such as kpackagelauncherqml) and applications having in general multiple desktop files. Thus each desktop file can put it's own name into the exec command. Diffs - autotests/kaboutdatatest.cpp 08690b7abed7727ab5610e41cfb124fc27cd88a5 src/lib/kaboutdata.h 134819b1ee32d5cf1e4f379b547e52e387dd674e src/lib/kaboutdata.cpp af10fc60053b294789f2813680299be2bc4b7a64 Diff: https://git.reviewboard.kde.org/r/125449/diff/ Testing --- See added unit test. For the command line parser I only tested whether it gets added to applications. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Removing "Automatically select icons" and "Change Cursor Over Icon"
El Dissabte, 26 de setembre de 2015, a les 15:41:09, David Edmundson va escriure: > Do it. > No point having options that do nothing, and I haven't noticed any > complaints about this function. Removed from the KCM and from gwenview. Cheers, Albert > > David ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125309: Support multiple X servers in the NETWM classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125309/ --- (Updated Sept. 29, 2015, 9:21 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Martin Gräßlin. Changes --- Submitted with commit 6404dde43127dbcecbc370ad57ae3523ca3c3325 by Thomas Lübking to branch master. Repository: kwindowsystem Description --- alteration review #125259 minus the autotests Significant difference is the creation and handling of the Atom enum. 1. Net::Utf8 makes no sense 2. Net::WmFoo re/adds ambiguity between _NET_WM and WM_, notably on _STATE (there's nothing such as XA_WM_STATE) 3. the most "important" grouping is whether it's WM_, NET_WM_, NET_, KDE_NET_, or ... UTF8, I'm not sure why one would add more enums (since this is internal API and the resolved type will always be xcb_atom_t - in worst case we run into errors on comparing the enums 4. I wanted to get rid of the explicit counter variable as well as any loose assignment between atom variable/enum and string. - So far on first creation of a NETRootInfo or NETWinInfo a static initialization of atoms was performed. This meant that the NET classes are only able to interact with the X server the first NET class is connected to. Normally applications don't need to interact with multiple X servers. An exception is kwin_wayland which needs a connection to its Xwayland server and on the x11 backend to the X server it renders to. So far KWin could not use the NET classes for it, causing the rendering window to e.g. not have a window title. This change removes the implicit constraint on one X server by creating a hash of connection and atoms. For each created NET class we check whether we have already resolved the atoms, if yes we reuse otherwise we create them. For the normal use case of one X11 connection the change should be rather minimal. Instead of performing the check whether the static atoms have been created, it now is a check whether the atoms for the connection have been created. The atoms are kept in a QSharedDataPointer ensuring that we don't needless copy the atoms into each class. CHANGELOG: Allow interacting with multiple X servers in the NETWM classes. Diffs - src/platforms/xcb/atoms_p.h PRE-CREATION src/platforms/xcb/netwm.cpp d99a925 src/platforms/xcb/netwm_p.h 917a86e Diff: https://git.reviewboard.kde.org/r/125309/diff/ Testing --- Thanks, Thomas Lübking ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125259: Support multiple X servers in the NETWM classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125259/ --- (Updated Sept. 30, 2015, 5:39 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Changes --- Submitted with commit 4d8394a5c4249e6b743aeb6d38bb2dda18266c42 by Martin Gräßlin to branch master. Repository: kwindowsystem Description --- So far on first creation of a NETRootInfo or NETWinInfo a static initialization of atoms was performed. This meant that the NET classes are only able to interact with the X server the first NET class is connected to. Normally applications don't need to interact with multiple X servers. An exception is kwin_wayland which needs a connection to its Xwayland server and on the x11 backend to the X server it renders to. So far KWin could not use the NET classes for it, causing the rendering window to e.g. not have a window title. This change removes the implicit constraint on one X server by creating a hash of connection and atoms. For each created NET class we check whether we have already resolved the atoms, if yes we reuse otherwise we create them. For the normal use case of one X11 connection the change should be rather minimal. Instead of performing the check whether the static atoms have been created, it now is a check whether the atoms for the connection have been created. The atoms are kept in a QSharedDataPointer ensuring that we don't needless copy the atoms into each class. CHANGELOG: Allow interacting with multiple X servers in the NETWM classes. [autotests] NETWM tests get a new X server per test Making use of new feature of allowing multiple X connections: start X server in init() instead of initTestCase(). Diffs - autotests/netwininfotestwm.cpp a98e12fd690b0250337c7588e1525af1d0dda38c autotests/netrootinfotestwm.cpp e918873a5281f6ecbcc1769de3dadcf8f6222f6a autotests/netwininfotestclient.cpp a5b10376b943ea914a9521b5c07f9ef13a65d2f1 src/platforms/xcb/netwm.cpp d99a925ad2b99d5e60ab1dafcb01400b4a6a4c93 src/platforms/xcb/netwm_p.h 917a86ed5b6c83f36e73bbc346360b943d457243 Diff: https://git.reviewboard.kde.org/r/125259/diff/ Testing --- see adjusted unit tests. Also tried it in kwin_wayland Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125259: Support multiple X servers in the NETWM classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125259/#review86140 --- Only going to push the autotest change now that the Thomas's patch version went in - Martin Gräßlin On Sept. 18, 2015, 10:19 a.m., Martin Gräßlin wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125259/ > --- > > (Updated Sept. 18, 2015, 10:19 a.m.) > > > Review request for KDE Frameworks. > > > Repository: kwindowsystem > > > Description > --- > > So far on first creation of a NETRootInfo or NETWinInfo a static > initialization of atoms was performed. This meant that the NET classes > are only able to interact with the X server the first NET class is > connected to. > > Normally applications don't need to interact with multiple X servers. > An exception is kwin_wayland which needs a connection to its Xwayland > server and on the x11 backend to the X server it renders to. So far > KWin could not use the NET classes for it, causing the rendering window > to e.g. not have a window title. > > This change removes the implicit constraint on one X server by > creating a hash of connection and atoms. For each created NET class > we check whether we have already resolved the atoms, if yes we reuse > otherwise we create them. > > For the normal use case of one X11 connection the change should be > rather minimal. Instead of performing the check whether the static > atoms have been created, it now is a check whether the atoms for the > connection have been created. The atoms are kept in a > QSharedDataPointer ensuring that we don't needless copy the atoms into > each class. > > CHANGELOG: Allow interacting with multiple X servers in the NETWM classes. > > [autotests] NETWM tests get a new X server per test > > Making use of new feature of allowing multiple X connections: > start X server in init() instead of initTestCase(). > > > Diffs > - > > autotests/netwininfotestwm.cpp a98e12fd690b0250337c7588e1525af1d0dda38c > autotests/netrootinfotestwm.cpp e918873a5281f6ecbcc1769de3dadcf8f6222f6a > autotests/netwininfotestclient.cpp a5b10376b943ea914a9521b5c07f9ef13a65d2f1 > src/platforms/xcb/netwm.cpp d99a925ad2b99d5e60ab1dafcb01400b4a6a4c93 > src/platforms/xcb/netwm_p.h 917a86ed5b6c83f36e73bbc346360b943d457243 > > Diff: https://git.reviewboard.kde.org/r/125259/diff/ > > > Testing > --- > > see adjusted unit tests. Also tried it in kwin_wayland > > > Thanks, > > Martin Gräßlin > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125425: Add the desktop file that is required for adding services to the context menu for files and directories
> On Sept. 28, 2015, 7:30 vorm., David Faure wrote: > > The filename not matching the servicetype name in it, is very confusing. > > > > How about deprecating KonqPopupMenu/Plugin, introducing a > > KIOServiceMenuPlugin servicetype, installing desktop files for both, > > querying for both and skipping the installation of > > konqpopupmenuplugin.desktop if the KIO version is > 5.15? If we change the ServiceType entry in the file, then every service menu will have to be changed, right? Not only those that are installed by applications and libraries that are hosted on git.kde.org (which we could at least find and fix), but also service menus that are released on kde-apps.org, or unreleased menus that users have written for themselves. I thought that it's unrealistic that this happens for every single service menu, that's why I thought that the KonqPopupMenu/Plugin type should be kept. Or am I overlooking something? If not, then I'm happy to change the file name - probably having a konqpopupmenuplugin.desktop in KIO is really less confusing than the ServiceType/file name mismatch. - Frank --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125425/#review86028 --- On Sept. 27, 2015, 6:18 nachm., Frank Reininghaus wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125425/ > --- > > (Updated Sept. 27, 2015, 6:18 nachm.) > > > Review request for KDE Frameworks and David Faure. > > > Bugs: 350769 > https://bugs.kde.org/show_bug.cgi?id=350769 > > > Repository: kio > > > Description > --- > > This is a modified version of the file konqpopupmenuplugin.desktop in > kde-baseapps (see > https://quickgit.kde.org/?p=kde-baseapps.git=blob=94a680ac215b4638a0c7cdd2b20bc7830b9619f2=35e8bc2992f48ffaff9007cfbf8faf3c856b18a3=lib%2Fkonq%2Fkonqpopupmenuplugin.desktop > for the latest version). > > I modified the name to kioservicemenuplugin.desktop because the file has not > been Konqueror-specific for quite some time. I also updated the 'Comment' > accordingly and removed the outdated translations. > > I hope I did that right - any comments are welcome! > > Note: Just like https://git.reviewboard.kde.org/r/124983/ this should > probably be pushed to master after the tagging for the next version because > of the translations. On the one hand, the translation of this 'Comment' might > not be that important because the it is not shown anywhere in the UI as far > as I know (it is shown in the 'Type' column in Dolphin though when viewing > the directory where this file is installed). But on the other hand, it might > be better to resolve both context menu issues in the same KIO release. What > do others think? > > > Diffs > - > > src/widgets/CMakeLists.txt 820cd34 > src/widgets/kioservicemenuplugin.desktop PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/125425/diff/ > > > Testing > --- > > Konsole service actions are shown in the context menu again. > > > Thanks, > > Frank Reininghaus > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
