D5801: Split XDGTest to allow testing both V5 and V6

[Martin Flöser]

graesslin accepted this revision.
graesslin added a comment.
This revision is now accepted and ready to land.


  Are you sure the API is so compatible that you can run it like that?

REPOSITORY
  R127 KWayland

BRANCH
  davidedmundson/xdgv6

REVISION DETAIL
  https://phabricator.kde.org/D5801

To: davidedmundson, #plasma, graesslin
Cc: graesslin, plasma-devel, #frameworks, ZrenBot, spstarr, progwolff, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, eliasp, sebas, apol, hein, 
lukas

D5775: Don't include the pid in the dbus path when on flatpak

[Jan Grulich]

jgrulich added a comment.


  In https://phabricator.kde.org/D5775#108558, @aacid wrote:
  
  > I don't think this is a fix.
  >
  > I can't really i good faith recommend people to use Okular from a flatpak 
if that means they can't start two okular instances.
  
  
  You have this problem even without this patch. When you now run two instances 
of Okular in flatpak then both will probably have same pid. Point of this patch 
is to make the dbus name predictable so you can allow access to it in flatpak 
manifest.

REPOSITORY
  R271 KDBusAddons

REVISION DETAIL
  https://phabricator.kde.org/D5775

To: apol, #frameworks, jgrulich
Cc: aacid

D5805: include directory should contains all directory from pkg-config

[Xuetian Weng]

xuetianweng added reviewers: apol, aacid.

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D5805

To: xuetianweng, apol, aacid
Cc: #frameworks, #build_system

D5805: include directory should contains all directory from pkg-config

[Xuetian Weng]

xuetianweng created this revision.
Restricted Application added projects: Frameworks, Build System.
Restricted Application added subscribers: Build System, Frameworks.

REVISION SUMMARY
  For certain pkg-config file that depends on other pkg-config, e.g. pango
  depends on glib2, glib's include directory would be omitted from the target,
  which essentially make it useless since the target will not compile with
  the only directory that contains the specified header.

REPOSITORY
  R240 Extra CMake Modules

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D5805

AFFECTED FILES
  modules/ECMFindModuleHelpers.cmake

To: xuetianweng
Cc: #frameworks, #build_system

D5802: ViewPrivate, KateSearchBar, KateVi::MatchHighlighter: use selection foreground for search highlights

[Ivan Shapovalov]

intelfx edited the summary of this revision.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D5802

To: intelfx, #kdevelop, #ktexteditor, #kate
Cc: kwrite-devel, #frameworks

D5802: ViewPrivate, KateSearchBar, KateVi::MatchHighlighter: use selection foreground for search highlights

[Ivan Shapovalov]

intelfx edited the summary of this revision.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D5802

To: intelfx, #kdevelop, #ktexteditor, #kate
Cc: kwrite-devel, #frameworks

D5802: ViewPrivate, KateSearchBar, KateVi::MatchHighlighter: use selection foreground for search highlights

[Ivan Shapovalov]

intelfx created this revision.
Restricted Application added subscribers: Frameworks, kwrite-devel.
Restricted Application added a project: Frameworks.

REVISION SUMMARY
  This is not an actual pull-request but rather an RFC (request for comments) 
from
  the KTextEditor, Kate and KDevelop developers, because I failed to solicit any
  feedback on the kdevelop-devel@ and kwrite-devel@ mailing lists.
  
  
(http://kde.6490.n7.nabble.com/Properly-porting-Solarized-to-Kate-KDevelop-need-to-change-behavior-of-search-result-highlighting-td1655274.html)
  
  So, I'm trying to make an exact port of Solarized to Kate/KDevelop and it 
looks
  like Solarized is not compatible with Kate's search result highlighting 
behavior:
  it requires search/replace highlight regions to use selection foreground and 
not
  the normal one. You can find the details in the linked archive post.
  
  Moreover, seems like kdevplatform's context browser plugin hints at behavior
  sought by me (but implements it incorrectly).
  
  
(https://github.com/KDE/kdevplatform/blob/master/plugins/contextbrowser/contextbrowser.cpp#L657)
  
  However, just making that change will make Kate/KDevelop incompatible with all
  existing color schemes. Hence, how do I proceed?

REPOSITORY
  R39 KTextEditor

BRANCH
  selection-foreground-for-search-highlights

REVISION DETAIL
  https://phabricator.kde.org/D5802

AFFECTED FILES
  src/search/katesearchbar.cpp
  src/view/kateview.cpp
  src/vimode/emulatedcommandbar/matchhighlighter.cpp

To: intelfx, #kdevelop, #ktexteditor, #kate
Cc: kwrite-devel, #frameworks

D5801: Split XDGTest to allow testing both V5 and V6

[David Edmundson]

davidedmundson created this revision.
Restricted Application added projects: Plasma on Wayland, Frameworks.
Restricted Application added subscribers: Frameworks, plasma-devel.

REVISION SUMMARY
  We want to test V6 using the exact same tests.
  
  We already use the QtTest rows inside the XdgClient, using that also for
  this separation gets quite complicated.

TEST PLAN
  Current test still passes.

REPOSITORY
  R127 KWayland

BRANCH
  davidedmundson/xdgv6

REVISION DETAIL
  https://phabricator.kde.org/D5801

AFFECTED FILES
  autotests/client/CMakeLists.txt
  autotests/client/test_xdg_shell.cpp
  autotests/client/test_xdg_shell_v5.cpp

To: davidedmundson, #plasma
Cc: plasma-devel, #frameworks, ZrenBot, spstarr, progwolff, lesliezhai, 
ali-mohamed, jensreuterberg, abetts, eliasp, sebas, apol, hein, lukas

D5799: Rebase Less syntax highlighting on SCSS one

[Grzegorz Szymaszek]

gszymaszek created this revision.
gszymaszek added a project: Framework: Syntax Hightlighting.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: Frameworks.

REVISION SUMMARY
  I’ve rebased Less syntax highlighting definitions on those from current SCSS 
syntax. Valid Less code is now mostly supported (I’ve tested this diff using 
various code snippets from “Features of the Less Language” 
); bug 369277 (“LessCSS syntax problem”) 
 is solved.
  
  Other notes:
  
  - “LESSCSS” name should probably be changed to just “Less”
  - colours (`defStyleNum`) have changed a lot in this diff
  - I’ve added some CSS properties from 
https://www.w3.org/Style/CSS/all-properties and colours from 
https://drafts.csswg.org/css-color-3/#svg-color, perhaps they should be added 
to CSS and SCSS files as well?
  
  Not supported:
  
  - invalid properties, like “padding-3” (properties cannot contain digits)
  - `:nth-child` parameters

REPOSITORY
  R216 Syntax Highlighting

REVISION DETAIL
  https://phabricator.kde.org/D5799

AFFECTED FILES
  data/syntax/less.xml

To: gszymaszek, #framework_syntax_hightlighting
Cc: #frameworks, cullmann, vkrause, dhaumann

D5775: Don't include the pid in the dbus path when on flatpak

[Albert Astals Cid]

aacid added a comment.


  I don't think this is a fix.
  
  I can't really i good faith recommend people to use Okular from a flatpak if 
that means they can't start two okular instances.

REPOSITORY
  R271 KDBusAddons

REVISION DETAIL
  https://phabricator.kde.org/D5775

To: apol, #frameworks, jgrulich
Cc: aacid

D5775: Don't include the pid in the dbus path when on flatpak

[Aleix Pol Gonzalez]

apol added a comment.


  In https://phabricator.kde.org/D5775#108315, @aacid wrote:
  
  > This means we get the same path if we start the process twice, does it 
still work? Don't you get some kind of collision at the dbus level?
  
  
  Yes, with this patch you can only open 1 of the applications (despite 
multiple). This is the error I get:
  
katomic(3)/(default) unknown: "Couldn't register name 'org.kde.katomic' 
with DBUS - another process owns it already!"
  
  While this is a regression, we'll still need to come up with an alternative, 
it will be an alternative ad-hoc to flatpak (and potentially anything else 
wrapping dbus).

REPOSITORY
  R271 KDBusAddons

REVISION DETAIL
  https://phabricator.kde.org/D5775

To: apol, #frameworks, jgrulich
Cc: aacid

D5783: Use application name instead of pid when creating SNI dbus service

[Jan Grulich]

This revision was automatically updated to reflect the committed changes.
Closed by commit R289:0d2f45ed3033: Use application name instead of pid when 
creating SNI dbus service (authored by jgrulich).

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D5783?vs=14361&id=14364

REVISION DETAIL
  https://phabricator.kde.org/D5783

AFFECTED FILES
  src/kstatusnotifieritemdbus_p.cpp

To: jgrulich, apol, mart
Cc: mart, #frameworks

D5783: Use application name instead of pid when creating SNI dbus service

[Jan Grulich]

jgrulich added a comment.


  Using applicationName-pid you cannot guarantee the pid will be always 1 or 2, 
you can have e.g a special launcher for an app doing some stuff and then you 
end up with much higher pid.

REPOSITORY
  R289 KNotifications

BRANCH
  application-dbus (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D5783

To: jgrulich, apol, mart
Cc: mart, #frameworks

D5783: Use application name instead of pid when creating SNI dbus service

[Marco Martin]

mart accepted this revision.
mart added a comment.
This revision is now accepted and ready to land.


  definitely better!
  i don't know whether we can afford to change it in any way outside the sanbox 
and not break things..
  it may make sense to use applicationName-pid at least inside the sandbox, 
maybe outside as well if affordable?
  (so you would have applicationName-1 applicationName-2 etc in the sandbox 
which still make sense

REPOSITORY
  R289 KNotifications

BRANCH
  application-dbus (branched from master)

REVISION DETAIL
  https://phabricator.kde.org/D5783

To: jgrulich, apol, mart
Cc: mart, #frameworks

Re: Android bulding guide

[Fernando Theirs]

Hi David!

Yes, that was just a mistake when I copied some code. I could finally make
my .pro and compile the library in QtCreator.

Thanks!!

2017-05-06 6:21 GMT-03:00 David Faure :

> On jeudi 4 mai 2017 17:19:57 CEST Fernando Theirs wrote:
> > Hi everyone!
> >
> > I'm working with Qt and I have to port a Linux application to Android.
> > Basically I need to manage some compressed files (targz, zip, among
> others)
> > and in Qt Forum they recommend me to use KArchive.
> >
> > I started working with Qt only a year ago and I'm still a rookie. I could
> > not find binaries for this library and the source code uses CMake (I was
> > expecting a .pro :/) so it's getting really hard for me to get it work.
> >
> > Asking to the same guy that recommended me the library and following his
> > indications I could compile KArchive for Linux and I'm testing it but I
> > can't understand very well the documentation.
> >
> > 1) Using KTar I could create a tar.gz with two txt files with the
> following
> > code:
> >
> > QString input =   "/home/ferni/QtBuild/KArchiveTest/testTar.txt";
> > QString input2 = "/home/ferni/QtBuild/KArchiveTest/testTar2.txt";
> > QString output = "/home/ferni/QtBuild/KArchiveTest/testTar.tar.gz";
> >
> > KTar archive(output, "application/x-gzip");
> > // Prepare the archive for writing.
> > if (!archive.open(QIODevice::ReadOnly)) {
>
> Don't you mean WriteOnly here?
>
> >  // Failed to open file.
> >  return 1;
> >  }
> >
> > // Create or open an archive
> > archive.addLocalFile(input, input);
> > archive.addLocalFile(input2, input2);
> > archive.close();
> >
> > My question is: how can I decompress the file that I created?
>
> Using KTar again, this time with ReadOnly ;-)
> See the KArchive API (base class for KTar).
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>