D18516: Fix end of folding region in rules with lookAhead=true

[Nibaldo González]

nibags added a comment.


  Some highlighters use endRegion+lookAhead to determine the end of a region 
when a new one starts, that is, they don't consider the text with 
endRegion+lookAhead as part of the fold region. This behavior was present 
before the implementation of KSyntaxHighlighting and, apparently, is no longer 
from the commit: c004f3f787b2 

  
  This problem is noticeable when hiding/showing a region: when a region 
collapses, the first line of the next region is also included (for example, in 
the `.diff` files). By doing a search: 
`(endRegion="[^>]*lookAhead="true"|lookAhead="true"[^>]*endRegion=")` in 
"data/syntax/" I can see the affected files. I leave some examples attached.
  
  Perhaps another solution is better, such as adding some attribute, such as 
`lookAheadEndRegion="true"`, for the rules that need it. This way you can 
control the behavior in the C ++ preprocessor and in other languages.
  
  F6571368: folding-test.zip 

REPOSITORY
  R216 Syntax Highlighting

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

To: nibags, #framework_syntax_highlighting, cullmann, dhaumann
Cc: andreasgr, kwrite-devel, kde-frameworks-devel, hase, michaelh, ngraham, 
bruns, demsking, cullmann, sars, dhaumann

D18516: Fix end of folding region in rules with lookAhead=true

[Nibaldo González]

nibags removed a reviewer: KTextEditor.

REPOSITORY
  R216 Syntax Highlighting

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

To: nibags, #framework_syntax_highlighting, cullmann, dhaumann, #ktexteditor
Cc: andreasgr, kwrite-devel, kde-frameworks-devel, hase, michaelh, ngraham, 
bruns, demsking, cullmann, sars, dhaumann

D17991: Refactor the way device backends are built and registered

[Pino Toscano]

pino added a comment.


  ping?

REPOSITORY
  R245 Solid

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

To: pino
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D18563: Don't allow '/' in new directory's name

[Shubham]

shubham edited the test plan for this revision.

REPOSITORY
  R241 KIO

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

To: shubham, ngraham, #frameworks, #dolphin
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D18563: Don't allow '/' in new directory's name

[Shubham]

shubham added a comment.


  If there already exists a folder named a, then creating directory named a/b 
still works, and creates a child directory named b inside a.

REPOSITORY
  R241 KIO

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

To: shubham, ngraham, #frameworks, #dolphin
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D18563: Don't allow '/' in new directory's name

[Shubham]

shubham edited the test plan for this revision.

REPOSITORY
  R241 KIO

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

To: shubham, ngraham, #frameworks, #dolphin
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D18563: Don't allow '/' in new directory's name

[Shubham]

shubham marked an inline comment as done.

REPOSITORY
  R241 KIO

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

To: shubham, ngraham, #frameworks, #dolphin
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D18563: Don't allow '/' in new directory's name

[Shubham]

shubham updated this revision to Diff 50410.
shubham added a comment.


  Don't create directory tree on Windows, instead create a directory

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18563?vs=50367=50410

BRANCH
  dir

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

AFFECTED FILES
  src/filewidgets/knewfilemenu.cpp

To: shubham, ngraham, #frameworks, #dolphin
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D18450: Add extractor for AppImage files

[TheAssassin]

TheAssassin added a comment.


  In D18450#400865 , @astippich 
wrote:
  
  > I am having troubles getting it to build (Kubuntu 18.10). Unfortunately, I 
could not find pre-build packages for libappimage. I have overcome two small 
issues in building libappimage, but now I can't get it to work in KFileMetaData 
because cmake complains that LIBAPPIMAGE_BINARIES is not set. Is that me doing 
something stupid? Anyway, I cannot test
  
  
  I have no clue what `LIBAPPIMAGE_BINARIES` is, but it looks like a CMake 
internal variable. Can you please open an issue on GitHub? Then, the AppImage 
team can help you.

REPOSITORY
  R286 KFileMetaData

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

To: kossebau, #baloo
Cc: TheAssassin, astippich, broulik, kde-frameworks-devel, ashaposhnikov, 
michaelh, spoorun, ngraham, bruns, abrahams

D18450: Add extractor for AppImage files

[Friedrich W. H. Kossebau]

kossebau added a comment.


  In D18450#400865 , @astippich 
wrote:
  
  > I am having troubles getting it to build (Kubuntu 18.10). Unfortunately, I 
could not find pre-build packages for libappimage. I have overcome two small 
issues in building libappimage, but now I can't get it to work in KFileMetaData 
because cmake complains that LIBAPPIMAGE_BINARIES is not set. Is that me doing 
something stupid? Anyway, I cannot test
  
  
  "LIBAPPIMAGE_BINARIES"? I am not aware of that variable in this patch or 
libappimage. @astippich  what have been your issues exactly you need to 
overcome, and how did you overcome them?
  
  BTW, if the build system is broken here with the self-built version you tried 
with, it is also broken in kio-extras, where libappimage is used to extract the 
icon by the appimage thumbnailer plugin, where the same logic is used.
  @broulik As author of the appimage thumbnailer, any hints from your side (or 
testing :) )?

REPOSITORY
  R286 KFileMetaData

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

To: kossebau, #baloo
Cc: astippich, broulik, kde-frameworks-devel, ashaposhnikov, michaelh, spoorun, 
ngraham, bruns, abrahams

D18434: exiv2extractor: add support for bmp, gif, webp, tga

[Friedrich W. H. Kossebau]

This revision was automatically updated to reflect the committed changes.
Closed by commit R286:6bc922351db0: exiv2extractor: add support for bmp, gif, 
webp, tga (authored by kossebau).

REPOSITORY
  R286 KFileMetaData

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18434?vs=50016=50400

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

AFFECTED FILES
  src/extractors/CMakeLists.txt
  src/extractors/exiv2extractor.cpp

To: kossebau, #baloo, #dolphin, astippich
Cc: aacid, kde-frameworks-devel, ashaposhnikov, michaelh, astippich, spoorun, 
ngraham, bruns, abrahams

D16894: [ECM] use a macro to add compiler flags conditionally

[René J . V . Bertin]

rjvbb set the repository for this revision to R240 Extra CMake Modules.

REPOSITORY
  R240 Extra CMake Modules

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

To: rjvbb, #build_system, kfunk
Cc: dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, #build_system, 
michaelh, ngraham, bruns

D16894: [ECM] use a macro to add compiler flags conditionally

[René J . V . Bertin]

rjvbb updated this revision to Diff 50399.
rjvbb added a comment.


  Renamed macro and parameter names as announced in my last comment.

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D16894?vs=45786=50399

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

AFFECTED FILES
  kde-modules/KDECompilerSettings.cmake
  kde-modules/KDEFrameworkCompilerSettings.cmake
  modules/ECMAddCompilerFlag.cmake

To: rjvbb, #build_system, kfunk
Cc: dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, #build_system, 
michaelh, ngraham, bruns

D16894: [ECM] use a macro to add compiler flags conditionally

[René J . V . Bertin]

rjvbb added a comment.


  In D16894#400949 , @dfaure wrote:
  
  > This makes sense to me. Just the name "SUPPORTED_IF" is strange, when 
reading that, one thinks "well, if we know the compiler flag is supported, why 
are we testing that it is?".
  
  
  I agree it looks strange, but apparently the combination with the macro name 
isn't as unambiguous as I hoped.
  
  The idea is: add the given option(s) but only If they are Supported by the 
compiler ... and they are Supported If the given expression is true.
  
  > I think this should be something like TRY_IF.
  
  That reads nicer, but isn't exact either because a priori there will be no 
more trying if the expression is true...
  
  I'll change the macro name to `ECM_ADD__FLAGS_CONDITIONALLY` and the 
parameter name to `CONDITION`, let's see how that works out.
  
  > Then it's clearer that no harm will occur if we set a too low compiler 
version after TRY_IF, it's just an optimization to avoid e.g. testing all gcc 
flags on MSVC and vice-versa.
  
  Uhm? That was not the intention. Currently if a TRY_IF condition is present 
then it is the only criterium used, UNLESS the compiler is Clang/AppleClang on 
APPLE. In that latter case the compiler is queried; this is also the case when 
no conditional expression is specified.
  
  I can of course inverse that logic, and make the condition a filter for when 
to query the compiler. At first sight I'd say that the conditional expressions 
won't need adapting but I have a feeling it might not be as simple.

REPOSITORY
  R240 Extra CMake Modules

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

To: rjvbb, #build_system, kfunk
Cc: dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, #build_system, 
michaelh, ngraham, bruns

D18547: Don't enable -Wzero-as-null-pointer-constant on apple clang

[René J . V . Bertin]

rjvbb added a comment.


  > like René says, this is quite surprising
  
  Hmmm, did I say exactly that? :)
  
  The surpising bit is that this hasn't been an issue for much longer although 
maybe even that is not so surprising.
  
  I continue to think that the check is not reliable as is. For instance, on my 
10.9.5 system:
  
> /usr/bin/clang --version
Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
  
  this compiler version does NOT support the flag in question here, as evident 
from the corresponding stock version (3.5). Later Apple clang versions no 
longer show the equivalence info but continue to use a versioning that is ahead 
of stock version numbers.
  This particular version is reported by CMake as `AppleClang 6.0.0.657` on 
the terminal, and `CMAKE_CXX_COMPILER_VERSION "6.0.0.657"` internally, iow, 
"not less than 5.0.0" ...

REPOSITORY
  R240 Extra CMake Modules

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

To: vonreth, aacid, apol, dfaure, rjvbb, bcooksley
Cc: aacid, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D18475: Add AsciiDoc support

[Nibaldo González]

nibags added a comment.


  If you are only going to use the "admonition" keywords list for 
autocompletion, you could add them to the end of the context "section" or 
"start", keeping the attribute (Normal). I have done this in some highlight 
files

REPOSITORY
  R216 Syntax Highlighting

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

To: andreasgr, #framework_syntax_highlighting
Cc: dhaumann, nibags, kwrite-devel, kde-frameworks-devel, 
#framework_syntax_highlighting, bmortimer, hase, michaelh, genethomas, ngraham, 
bruns, demsking, cullmann, vkrause, sars

D18475: Add AsciiDoc support

[Andreas Gratzer]

andreasgr updated this revision to Diff 50391.
andreasgr added a comment.


  Fix diff.

REPOSITORY
  R216 Syntax Highlighting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18475?vs=50390=50391

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

AFFECTED FILES
  autotests/input/asciidoc.adoc
  data/syntax/asciidoc.xml

To: andreasgr, #framework_syntax_highlighting
Cc: dhaumann, nibags, kwrite-devel, kde-frameworks-devel, 
#framework_syntax_highlighting, bmortimer, hase, michaelh, genethomas, ngraham, 
bruns, demsking, cullmann, vkrause, sars

D17137: KTextEditor: File menu: Put Save, Print and Export in submenus

[Milian Wolff]

mwolff resigned from this revision.

REPOSITORY
  R39 KTextEditor

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

To: gregormi, #kate, #kdevelop
Cc: loh.tar, anthonyfieroni, ngraham, cullmann, flherne, dhaumann, 
kwrite-devel, kde-frameworks-devel, hase, michaelh, bruns, demsking, sars

D18475: Add AsciiDoc support

[Andreas Gratzer]

andreasgr updated this revision to Diff 50390.
andreasgr added a comment.


  - Added test AsciiDoc.

REPOSITORY
  R216 Syntax Highlighting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18475?vs=50388=50390

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

AFFECTED FILES
  autotests/input/asciidoc.adoc

To: andreasgr, #framework_syntax_highlighting
Cc: dhaumann, nibags, kwrite-devel, kde-frameworks-devel, 
#framework_syntax_highlighting, bmortimer, hase, michaelh, genethomas, ngraham, 
bruns, demsking, cullmann, vkrause, sars

D18475: Add AsciiDoc support

[Andreas Gratzer]

andreasgr updated this revision to Diff 50388.
andreasgr added a comment.


  - Drop unused 'admonition' keyword list.
  - Rename itemData elements to start with capital letters.
  - Enable escaping in block and section titles.

REPOSITORY
  R216 Syntax Highlighting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18475?vs=50382=50388

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

AFFECTED FILES
  data/syntax/asciidoc.xml

To: andreasgr, #framework_syntax_highlighting
Cc: dhaumann, nibags, kwrite-devel, kde-frameworks-devel, 
#framework_syntax_highlighting, bmortimer, hase, michaelh, genethomas, ngraham, 
bruns, demsking, cullmann, vkrause, sars

D16894: [ECM] use a macro to add compiler flags conditionally

[David Faure]

dfaure added a comment.


  This makes sense to me. Just the name "SUPPORTED_IF" is strange, when reading 
that, one thinks "well, if we know the compiler flag is supported, why are we 
testing that it is?". I think this should be something like TRY_IF.
  Then it's clearer that no harm will occur if we set a too low compiler 
version after TRY_IF, it's just an optimization to avoid e.g. testing all gcc 
flags on MSVC and vice-versa.

REPOSITORY
  R240 Extra CMake Modules

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

To: rjvbb, #build_system, kfunk
Cc: dfaure, kfunk, apol, kde-frameworks-devel, kde-buildsystem, #build_system, 
michaelh, ngraham, bruns

D18547: Don't enable -Wzero-as-null-pointer-constant on apple clang

[David Faure]

dfaure accepted this revision.
dfaure added a comment.


  If it fixes the issue, this can go in, but like René says, this is quite 
surprising, since the default behavior (CMP0025 off) is that the compiler is 
called "Clang" on Apple platforms as well.
  See `cmake --help-policy CMP0025`

REPOSITORY
  R240 Extra CMake Modules

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

To: vonreth, aacid, apol, dfaure, rjvbb, bcooksley
Cc: aacid, kde-frameworks-devel, kde-buildsystem, michaelh, ngraham, bruns

D18380: KIO: make file dialog columns resizable again (and movable)

[Mark Gaiser]

markg added a comment.


  In D18380#400910 , @rjvbb wrote:
  
  > > But still, isn't there another way? Now the header and view are locked 
together. One doesn't work without the other.
  >
  > What's the problem with that? The custom header class isn't public. I did 
indeed use it for stuff that were not part of a class, or of the 
KDirOperatorDetailView class in earlier iterations. There's no hard reason for 
that, I just find it tidier (and it saves me from having to compile all other 
modules that import the kdiroperatordetail view headerfile when I change a 
detail that doesn't concern them).
  >
  > >   The thing that triggered me to comment wasn't any of that though. It's 
the "narrow mode". I cannot see how that wouldn't be seen as a bug by a user. 
With that little trick you're also overruling any font spacing settings the 
user might have had (in fontconfig) which is quite likely going to cause 
unexpected behavior and therefore bug reports.
  >
  > I'd say make a test case and convince us. You may have missed the fact that 
I'm no longer doing anything to the used font (the same in all columns). I'm 
just using the event flow to let Qt determine column widths using whatever 
information it wants, and then I "fixate" those widths in order to restore 
interactive mode. This is an admittedly complex way to do something that Qt 
doesn't allow us to do: 1) set interactive mode, 2) ask QHeaderView for the 
width that would be used in one of the automatic modes, 3) set those modes 
(with a minimum imposed on the name column).
  
  
  I know. I'm not attacking you here :) I've been in the same annoying 
situation countless of times when wanting to have this very feature. It's a 
pain Qt doesn't give it. But there are ways to solve it and yours is on the 
complicated side.
  
  > I can imagine that someone might file a bug about the name column getting a 
bit larger when resizing. In practice I'm not convinced many users will even 
notice this because it will happen only once, making the column more readable 
(and how much time does one spend resizing side-bars anyway). I think this is a 
bridge to take if and when we get there. A possible workaround would be to 
calculate our own minimum width in such a way that we arrive at the width Qt 
later decides to pick for some reason (for the default font at least).
  
  This is a typical "last mile" thingy. Yes, it works. But not as perfect as it 
could be which eventually is going to add up in hundreds of other "last mile" 
things. Each on their own not worth the time to fix. All together giving the 
user a "yep, they still need to work uit some bugs" feeling.
  
  > Something we (= a number of us) need to look into is what happens when you 
resize a view *after* a manual column adjustment, and what should happen in 
that case. Knowing that anything to make the manual adjustment permanent will 
only increase the code complexity.
  
  I'd say the last column will be the victim there. Just enable 
setStretchLastSection(true) (works in my example too) and let a resize be 
handled that way. This results in the view leaving all columns exactly as is 
when resizing except for the last column. The user still has to resize the name 
column to make it bigger/smaller and that very action should be stored and 
restored next time. It saves the hassle of trying to figure out what the user 
intended.
  
  > 
  > 
  >> The size calculation is not perfect
  > 
  > My initial implementation wasn't perfect either (Nate complained how it 
worked in narrow mode) ... and addressing that was what introduced most of the 
complexity.
  > 
  > At this point I have invested enough time and energy in what is essentially 
a behavioural detail. I like doing that kind of thing but I'm not motivated 
enough to start from scratch (I'll consider making little changes but not much 
more).
  
  Your work is well appreciated! It triggered me to look into it as well. 
Together we can probably figure out a perfect solution that does't leave any 
hiccups that the user will consider a bug, however short they might be. And as 
an added bonus might be used as a generic better QHeaderView version.
  
  p.s. This custom header view thing should definitely be a candidate for 
probably KItemViews. Not my version as-is, but the concept of having more 
flexibility in the header view.

REPOSITORY
  R241 KIO

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

To: rjvbb, ngraham, #frameworks, #dolphin, apol, dfaure, ahartmetz, markg
Cc: markg, cfeck, dhaumann, kwrite-devel, kde-frameworks-devel, michaelh, 
ngraham, bruns

D18563: Don't allow '/' in new directory's name

[Nathaniel Graham]

ngraham requested changes to this revision.
ngraham added reviewers: Frameworks, Dolphin.
ngraham added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> knewfilemenu.cpp:907
>  if (name.contains(QLatin1Char('/'))) {
> +// Allow creating directory tree on Windows
>  // If the name contains any slashes, use mkpath so that a/b/c works.

If Windows allows slashes in the filename, shouldn't they just be a part of the 
filename and not create a directory tree? If so, then we don't even need this 
`#ifdef` condition at all; `KIO::mkdir(url);` will take care of the behavior on 
each individual platform

REPOSITORY
  R241 KIO

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

To: shubham, ngraham, #frameworks, #dolphin
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D18380: KIO: make file dialog columns resizable again (and movable)

[Mark Gaiser]

markg added a comment.


  In D18380#400903 , @ngraham wrote:
  
  > In D18380#400896 , @markg wrote:
  >
  > > In QHeaderView code, what we want is "QHeaderView::Interactive" [1] 
followed by QHeaderView::resizeSection [2]. Exactly as [1] described! 
QHeaderView merely lacks a convenience function for this, that is what we have 
to implement!
  >
  >
  > Using that alone results in a visual and functional regression of the 
original problem we were trying to fix (that file dialogs don't have a sensible 
default view):
  >
  > F6570515: Regression.png 
  >
  > If we go with this route, I would want to make sure we preserve the current 
behavior of other columns being right-aligned, and also make sure that the Name 
column has a good default width. If we can ensure that, I'm all for it!
  
  
  Lol :)
  It wasn't meant as a direct drop-in replacement for Rene's patch. KIO 
probably sets more on the headerview that isn't applied now (i assume). And if 
it doesn't then some things do need to be set to make it look nice.  It's 
merely meant to demonstrate that you can change the width of a column to 
whatever you desire while keeping the resizable feature and without the need to 
catch events and do magic there.
  
  Anyhow, you basically want a "stretchFirstColumn" while keeping. I named it 
"stretchColumn" but as it is now it only works if one column uses it. You need 
more complex layouting to get that to work if you want to stretch over multiple 
columns. But that's not the case here.
  Here it is. [1: header], [2: source], and a example on how to use it [3]. 
This obviously is far from done, but again only to demonstrate. If you like 
this approach i can put some time in it to make it less sensitive to errors.
  **be aware** to call "stretchColumn" after you show the dialog! Otherwise the 
sizes haven't been calculated yet. If you do exec, you can get around it by 
doing a QTimer::singleShot.
  
  [1] https://p.sc2.nl/H1S-2DomE
  [2] https://p.sc2.nl/ryQ2hwoX4
  [3] https://p.sc2.nl/Bybanvj7V

REPOSITORY
  R241 KIO

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

To: rjvbb, ngraham, #frameworks, #dolphin, apol, dfaure, ahartmetz, markg
Cc: markg, cfeck, dhaumann, kwrite-devel, kde-frameworks-devel, michaelh, 
ngraham, bruns

D18475: Add AsciiDoc support

[Andreas Gratzer]

andreasgr added a comment.


  In D18475#400893 , @dhaumann wrote:
  
  > Running the katesyntaxhighlighting indexer tells me:
  >
  >   katehighlightingindexer::KeywordChecker::check: 
"syntax-highlighting/data/syntax/asciidoc.xml" Unused keyword lists: 
"admonition"
  >   
  >
  > Could you fix this? Usually, keyword completion should be context dependent 
anyways (currently a bug), so soon your unused list will indeed not have any 
effect.
  
  
  OK, I will remove it.
  I just added it as this supports word completion.
  
  > Besides: If you want to support specials like TODO, NOTE, ..., then please 
use IncludeRules and ##Alert (look into other files how it's done).
  
  These 'admonitions' are a different thing.
  They are a feature of AsciiDoc, have to align to specific formats and are 
rendered in the output (see 
https://asciidoctor.org/docs/user-manual/#admonition).
  
  Using alerts in comments is already supported the way you described.
  
  > Also, could you please change all itemData names to upper case naming? Eg. 
"replacement" -> "Replacement",  or "section title" -> Section Title", etc? All 
other highlighting files use this naming scheme, and it will be visible in the 
UI later when configuring the colors in Kate.
  
  Sure, no problem.
  
  > And what's still missing is a test file, also best licensed under MIT, that 
we can use for regression testing.
  
  Working on it.
  I understand a single AsciiDoc is expected?
  I have a set of 22 AsciiDocs I used for testing while creating the 
highlighting support and another one describing the things I know are 
currrently not working.
  At the moment I am merging them into a single one.
  
  Thanks for your feedback :)

REPOSITORY
  R216 Syntax Highlighting

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

To: andreasgr, #framework_syntax_highlighting
Cc: dhaumann, nibags, kwrite-devel, kde-frameworks-devel, 
#framework_syntax_highlighting, bmortimer, hase, michaelh, genethomas, ngraham, 
bruns, demsking, cullmann, vkrause, sars

D18380: KIO: make file dialog columns resizable again (and movable)

[René J . V . Bertin]

rjvbb added a comment.


  > But still, isn't there another way? Now the header and view are locked 
together. One doesn't work without the other.
  
  What's the problem with that? The custom header class isn't public. I did 
indeed use it for stuff that were not part of a class, or of the 
KDirOperatorDetailView class in earlier iterations. There's no hard reason for 
that, I just find it tidier (and it saves me from having to compile all other 
modules that import the kdiroperatordetail view headerfile when I change a 
detail that doesn't concern them).
  
  >   The thing that triggered me to comment wasn't any of that though. It's 
the "narrow mode". I cannot see how that wouldn't be seen as a bug by a user. 
With that little trick you're also overruling any font spacing settings the 
user might have had (in fontconfig) which is quite likely going to cause 
unexpected behavior and therefore bug reports.
  
  I'd say make a test case and convince us. You may have missed the fact that 
I'm no longer doing anything to the used font (the same in all columns). I'm 
just using the event flow to let Qt determine column widths using whatever 
information it wants, and then I "fixate" those widths in order to restore 
interactive mode. This is an admittedly complex way to do something that Qt 
doesn't allow us to do: 1) set interactive mode, 2) ask QHeaderView for the 
width that would be used in one of the automatic modes, 3) set those modes 
(with a minimum imposed on the name column).
  
  I can imagine that someone might file a bug about the name column getting a 
bit larger when resizing. In practice I'm not convinced many users will even 
notice this because it will happen only once, making the column more readable 
(and how much time does one spend resizing side-bars anyway). I think this is a 
bridge to take if and when we get there. A possible workaround would be to 
calculate our own minimum width in such a way that we arrive at the width Qt 
later decides to pick for some reason (for the default font at least).
  
  Something we (= a number of us) need to look into is what happens when you 
resize a view *after* a manual column adjustment, and what should happen in 
that case. Knowing that anything to make the manual adjustment permanent will 
only increase the code complexity.
  
  > The size calculation is not perfect
  
  My initial implementation wasn't perfect either (Nate complained how it 
worked in narrow mode) ... and addressing that was what introduced most of the 
complexity.
  
  At this point I have invested enough time and energy in what is essentially a 
behavioural detail. I like doing that kind of thing but I'm not motivated 
enough to start from scratch (I'll consider making little changes but not much 
more).

REPOSITORY
  R241 KIO

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

To: rjvbb, ngraham, #frameworks, #dolphin, apol, dfaure, ahartmetz, markg
Cc: markg, cfeck, dhaumann, kwrite-devel, kde-frameworks-devel, michaelh, 
ngraham, bruns

D18380: KIO: make file dialog columns resizable again (and movable)

[Nathaniel Graham]

ngraham added a comment.


  In D18380#400896 , @markg wrote:
  
  > In QHeaderView code, what we want is "QHeaderView::Interactive" [1] 
followed by QHeaderView::resizeSection [2]. Exactly as [1] described! 
QHeaderView merely lacks a convenience function for this, that is what we have 
to implement!
  
  
  Using that alone results in a visual and functional regression of the 
original problem we were trying to fix (that file dialogs don't have a sensible 
default view):
  
  F6570515: Regression.png 
  
  If we go with this route, I would want to make sure we preserve the current 
behavior of other columns being right-aligned, and also make sure that the Name 
column has a good default width. If we can ensure that, I'm all for it!

REPOSITORY
  R241 KIO

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

To: rjvbb, ngraham, #frameworks, #dolphin, apol, dfaure, ahartmetz, markg
Cc: markg, cfeck, dhaumann, kwrite-devel, kde-frameworks-devel, michaelh, 
ngraham, bruns

D18380: KIO: make file dialog columns resizable again (and movable)

[Mark Gaiser]

markg requested changes to this revision.
markg added a comment.
This revision now requires changes to proceed.


  I too would quite like the to have resizeable columns back.
  But the approach you've chosen looks a little too complicated. Also, the fact 
that KDirOperatorDetailView::event needs to know about your custom QHeaderView 
is a code smell. Sometimes you do indeed need logic like that to make things 
work. But still, isn't there another way? Now the header and view are locked 
together. One doesn't work without the other.
  
  The thing that triggered me to comment wasn't any of that though. It's the 
"narrow mode". I cannot see how that wouldn't be seen as a bug by a user. With 
that little trick you're also overruling any font spacing settings the user 
might have had (in fontconfig) which is quite likely going to cause unexpected 
behavior and therefore bug reports.
  
  Now let's take a step back. What do we really want? We want:
  
  - Have the first column resizable and calculate the optimal size when the 
user had not resized the column yet.
  - Restore that setting if the user had manually resized it.
  
  In QHeaderView code, what we want is "QHeaderView::Interactive" [1] followed 
by QHeaderView::resizeSection [2]. Exactly as [1] described! QHeaderView merely 
lacks a convenience function for this, that is what we have to implement!
  I quickly threw this in a test project (minus the state saving) and i ended 
up with this fairly minimal QHeaderView subclass [3: header], [4: source] and 
this sample to see how you use it [5]. Note that there is one quirk in there in 
the source. The size calculation is not perfect and will fail on longer 
strings! That likely needs to be extended to take the style and margins into 
account. Anyhow, the goal of this example is to show a different approach with 
a far smaller code footprint and be far easier to debug. Use it as you please :)
  
  [1] http://doc.qt.io/qt-5/qheaderview.html#ResizeMode-enum
  [2] http://doc.qt.io/qt-5/qheaderview.html#resizeSection
  [3] https://p.sc2.nl/r1RJBLsQ4
  [4] https://p.sc2.nl/BJlMSLimN
  [5] https://p.sc2.nl/SJIYI8jQV

REPOSITORY
  R241 KIO

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

To: rjvbb, ngraham, #frameworks, #dolphin, apol, dfaure, ahartmetz, markg
Cc: markg, cfeck, dhaumann, kwrite-devel, kde-frameworks-devel, michaelh, 
ngraham, bruns

D18475: Add AsciiDoc support

[Dominik Haumann]

dhaumann added a comment.


  Running the katesyntaxhighlighting indexer tells me:
  
katehighlightingindexer::KeywordChecker::check: 
"syntax-highlighting/data/syntax/asciidoc.xml" Unused keyword lists: 
"admonition"
  
  Could you fix this? Usually, keyword completion should be context dependent 
anyways (currently a bug), so soon your unused list will indeed not have any 
effect. Besides: If you want to support specials like TODO, NOTE, ..., then 
please use IncludeRules and ##Alert (look into other files how it's done).
  
  Also, could you please change all itemData names to upper case naming? Eg. 
"replacement" -> "Replacement",  or "section title" -> Section Title", etc? All 
other highlighting files use this naming scheme, and it will be visible in the 
UI later when configuring the colors in Kate.
  
  And what's still missing is a test file, also best licensed under MIT, that 
we can use for regression testing.

REPOSITORY
  R216 Syntax Highlighting

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

To: andreasgr, #framework_syntax_highlighting
Cc: dhaumann, nibags, kwrite-devel, kde-frameworks-devel, 
#framework_syntax_highlighting, bmortimer, hase, michaelh, genethomas, ngraham, 
bruns, demsking, cullmann, vkrause, sars

D18475: Add AsciiDoc support

[Andreas Gratzer]

andreasgr updated this revision to Diff 50382.
andreasgr added a comment.


  Drop custom colors and backgrounds.

REPOSITORY
  R216 Syntax Highlighting

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18475?vs=50263=50382

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

AFFECTED FILES
  data/syntax/asciidoc.xml

To: andreasgr, #framework_syntax_highlighting
Cc: dhaumann, nibags, kwrite-devel, kde-frameworks-devel, 
#framework_syntax_highlighting, bmortimer, hase, michaelh, genethomas, ngraham, 
bruns, demsking, cullmann, vkrause, sars

D18450: Add extractor for AppImage files

[Alexander Stippich]

astippich added a comment.


  I am having troubles getting it to build (Kubuntu 18.10). Unfortunately, I 
could not find pre-build packages for libappimage. I have overcome two small 
issues in building libappimage, but now I can't get it to work in KFileMetaData 
because cmake complains that LIBAPPIMAGE_BINARIES is not set. Is that me doing 
something stupid? Anyway, I cannot test

REPOSITORY
  R286 KFileMetaData

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

To: kossebau, #baloo
Cc: astippich, broulik, kde-frameworks-devel, ashaposhnikov, michaelh, spoorun, 
ngraham, bruns, abrahams

D18434: exiv2extractor: add support for bmp, gif, webp, tga

[Alexander Stippich]

astippich accepted this revision.
This revision is now accepted and ready to land.

REPOSITORY
  R286 KFileMetaData

BRANCH
  covergiftgabmp

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

To: kossebau, #baloo, #dolphin, astippich
Cc: aacid, kde-frameworks-devel, ashaposhnikov, michaelh, astippich, spoorun, 
ngraham, bruns, abrahams

KDE CI: Frameworks » kimageformats » kf5-qt5 SUSEQt5.12 - Build # 4 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kimageformats/job/kf5-qt5%20SUSEQt5.12/4/
 Project:
kf5-qt5 SUSEQt5.12
 Date of build:
Sun, 27 Jan 2019 12:17:20 +
 Build duration:
3 min 45 sec and counting
   BUILD ARTIFACTS
  abi-compatibility-results.yaml
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 2 test(s), Passed: 9 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.kimageformats_read_tgaFailed: projectroot.autotests.kimageformats_write_tga
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report100%
(3/3)76%
(13/17)76%
(13/17)41%
(1496/3614)33%
(667/2031)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(3/3)100%
(3/3)70%
(263/375)50%
(72/144)src.imageformats82%
(9/11)82%
(9/11)40%
(1229/3107)32%
(593/1829)tests33%
(1/3)33%
(1/3)3%
(4/132)3%
(2/58)

KDE CI: Frameworks » kimageformats » kf5-qt5 SUSEQt5.10 - Build # 6 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kimageformats/job/kf5-qt5%20SUSEQt5.10/6/
 Project:
kf5-qt5 SUSEQt5.10
 Date of build:
Sun, 27 Jan 2019 12:17:20 +
 Build duration:
1 min 29 sec and counting
   BUILD ARTIFACTS
  abi-compatibility-results.yaml
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 2 test(s), Passed: 9 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.kimageformats_read_tgaFailed: projectroot.autotests.kimageformats_write_tga
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report100%
(3/3)76%
(13/17)76%
(13/17)41%
(1496/3614)33%
(667/2031)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(3/3)100%
(3/3)70%
(263/375)50%
(72/144)src.imageformats82%
(9/11)82%
(9/11)40%
(1229/3107)32%
(593/1829)tests33%
(1/3)33%
(1/3)3%
(4/132)3%
(2/58)

KDE CI: Frameworks » kimageformats » kf5-qt5 FreeBSDQt5.12 - Build # 7 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kimageformats/job/kf5-qt5%20FreeBSDQt5.12/7/
 Project:
kf5-qt5 FreeBSDQt5.12
 Date of build:
Sun, 27 Jan 2019 12:17:20 +
 Build duration:
1 min 6 sec and counting
   JUnit Tests
  Name: projectroot Failed: 2 test(s), Passed: 9 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.kimageformats_read_tgaFailed: projectroot.autotests.kimageformats_write_tga

KDE CI: Frameworks » kimageformats » kf5-qt5 SUSEQt5.12 - Build # 3 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kimageformats/job/kf5-qt5%20SUSEQt5.12/3/
 Project:
kf5-qt5 SUSEQt5.12
 Date of build:
Sun, 27 Jan 2019 11:51:30 +
 Build duration:
3 min 58 sec and counting
   BUILD ARTIFACTS
  abi-compatibility-results.yaml
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 3 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.kimageformats_read_tgaFailed: projectroot.autotests.kimageformats_read_xcfFailed: projectroot.autotests.kimageformats_write_tga
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report100%
(3/3)76%
(13/17)76%
(13/17)41%
(1473/3613)32%
(655/2027)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(3/3)100%
(3/3)70%
(263/375)50%
(72/144)src.imageformats82%
(9/11)82%
(9/11)39%
(1206/3106)32%
(581/1825)tests33%
(1/3)33%
(1/3)3%
(4/132)3%
(2/58)

KDE CI: Frameworks » kimageformats » kf5-qt5 SUSEQt5.10 - Build # 5 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kimageformats/job/kf5-qt5%20SUSEQt5.10/5/
 Project:
kf5-qt5 SUSEQt5.10
 Date of build:
Sun, 27 Jan 2019 11:51:30 +
 Build duration:
1 min 34 sec and counting
   BUILD ARTIFACTS
  abi-compatibility-results.yaml
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 3 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.kimageformats_read_tgaFailed: projectroot.autotests.kimageformats_read_xcfFailed: projectroot.autotests.kimageformats_write_tga
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report100%
(3/3)76%
(13/17)76%
(13/17)41%
(1473/3613)32%
(655/2027)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(3/3)100%
(3/3)70%
(263/375)50%
(72/144)src.imageformats82%
(9/11)82%
(9/11)39%
(1206/3106)32%
(581/1825)tests33%
(1/3)33%
(1/3)3%
(4/132)3%
(2/58)

KDE CI: Frameworks » kimageformats » kf5-qt5 FreeBSDQt5.12 - Build # 6 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kimageformats/job/kf5-qt5%20FreeBSDQt5.12/6/
 Project:
kf5-qt5 FreeBSDQt5.12
 Date of build:
Sun, 27 Jan 2019 11:51:30 +
 Build duration:
47 sec and counting
   JUnit Tests
  Name: projectroot Failed: 3 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.kimageformats_read_tgaFailed: projectroot.autotests.kimageformats_read_xcfFailed: projectroot.autotests.kimageformats_write_tga

KDE CI: Frameworks » kimageformats » kf5-qt5 SUSEQt5.12 - Build # 2 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kimageformats/job/kf5-qt5%20SUSEQt5.12/2/
 Project:
kf5-qt5 SUSEQt5.12
 Date of build:
Sun, 27 Jan 2019 11:29:50 +
 Build duration:
4 min 4 sec and counting
   BUILD ARTIFACTS
  abi-compatibility-results.yaml
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 3 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.kimageformats_read_tgaFailed: projectroot.autotests.kimageformats_read_xcfFailed: projectroot.autotests.kimageformats_write_tga
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report100%
(3/3)76%
(13/17)76%
(13/17)41%
(1469/3608)32%
(653/2025)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(3/3)100%
(3/3)70%
(263/375)50%
(72/144)src.imageformats82%
(9/11)82%
(9/11)39%
(1202/3101)32%
(579/1823)tests33%
(1/3)33%
(1/3)3%
(4/132)3%
(2/58)

KDE CI: Frameworks » kimageformats » kf5-qt5 SUSEQt5.10 - Build # 4 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kimageformats/job/kf5-qt5%20SUSEQt5.10/4/
 Project:
kf5-qt5 SUSEQt5.10
 Date of build:
Sun, 27 Jan 2019 11:29:50 +
 Build duration:
1 min 25 sec and counting
   BUILD ARTIFACTS
  abi-compatibility-results.yaml
   JUnit Tests
  Name: (root) Failed: 0 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 1 test(s)Name: projectroot Failed: 3 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.kimageformats_read_tgaFailed: projectroot.autotests.kimageformats_read_xcfFailed: projectroot.autotests.kimageformats_write_tga
   Cobertura Report
  
   Project Coverage Summary
  
   Name
  PackagesFilesClassesLinesConditionalsCobertura Coverage Report100%
(3/3)76%
(13/17)76%
(13/17)41%
(1469/3608)32%
(653/2025)Coverage Breakdown by Package
Name
   FilesClassesLinesConditionalsautotests100%
(3/3)100%
(3/3)70%
(263/375)50%
(72/144)src.imageformats82%
(9/11)82%
(9/11)39%
(1202/3101)32%
(579/1823)tests33%
(1/3)33%
(1/3)3%
(4/132)3%
(2/58)

KDE CI: Frameworks » kimageformats » kf5-qt5 FreeBSDQt5.12 - Build # 5 - Still Unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/kimageformats/job/kf5-qt5%20FreeBSDQt5.12/5/
 Project:
kf5-qt5 FreeBSDQt5.12
 Date of build:
Sun, 27 Jan 2019 11:29:50 +
 Build duration:
43 sec and counting
   JUnit Tests
  Name: projectroot Failed: 3 test(s), Passed: 8 test(s), Skipped: 0 test(s), Total: 11 test(s)Failed: projectroot.autotests.kimageformats_read_tgaFailed: projectroot.autotests.kimageformats_read_xcfFailed: projectroot.autotests.kimageformats_write_tga

D18526: Fix memory leak when passing icon data to Java

[Volker Krause]

This revision was automatically updated to reflect the committed changes.
Closed by commit R289:874cb8e5a728: Fix memory leak when passing icon data to 
Java (authored by vkrause).

REPOSITORY
  R289 KNotifications

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D18526?vs=50262=50372

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

AFFECTED FILES
  src/notifybyandroid.cpp

To: vkrause, apol
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

KDE CI: Frameworks » knotifications » kf5-qt5 WindowsMSVCQt5.11 - Build # 37 - Still unstable!

[CI System]

BUILD UNSTABLE
 Build URL
https://build.kde.org/job/Frameworks/job/knotifications/job/kf5-qt5%20WindowsMSVCQt5.11/37/
 Project:
kf5-qt5 WindowsMSVCQt5.11
 Date of build:
Sun, 27 Jan 2019 10:18:40 +
 Build duration:
12 min and counting
   JUnit Tests
  Name: projectroot Failed: 1 test(s), Passed: 0 test(s), Skipped: 0 test(s), Total: 1 test(s)Failed: projectroot.autotests.KNotificationTest

KDE CI: Frameworks » knotifications » kf5-qt5 AndroidQt5.11 - Build # 15 - Still Failing!

[CI System]

BUILD FAILURE
 Build URL
https://build.kde.org/job/Frameworks/job/knotifications/job/kf5-qt5%20AndroidQt5.11/15/
 Project:
kf5-qt5 AndroidQt5.11
 Date of build:
Sun, 27 Jan 2019 10:18:39 +
 Build duration:
2 min 23 sec and counting
   CONSOLE OUTPUT
  [...truncated 211 lines...] * Qt5TextToSpeech, Qt text to speech module   Required to build text to speech notification support * PkgConfig * Qt5Test (required version >= 5.10.0)-- The following REQUIRED packages have been found: * ECM (required version >= 5.54.0), Extra CMake Modules.,  * Qt5Gui (required version >= 5.11.3) * Qt5Widgets * Qt5AndroidExtras * Gradle * Qt5 (required version >= 5.10.0) * Qt5Core * KF5WindowSystem (required version >= 5.54.0) * KF5Config (required version >= 5.54.0) * KF5Codecs (required version >= 5.54.0) * KF5CoreAddons (required version >= 5.54.0)-- The following features have been disabled: * QCH, API documentation in QCH format (for e.g. Qt Assistant, Qt Creator & KDevelop)-- The following OPTIONAL packages have not been found: * X11 * Canberra, Library for generating event sounds,Needed to build audio notification support * Phonon4Qt5 (required version >= 4.6.60), Qt-based audio library   Needed to build audio notification support when Canberra isn't available * dbusmenu-qt5, DBusMenuQt,Support for notification area menus via the DBusMenu protocol-- Configuring done-- Generating done-- Build files have been written to: /home/user/workspace/Frameworks/knotifications/kf5-qt5 AndroidQt5.11/build[Pipeline] }[Pipeline] // stage[Pipeline] stage[Pipeline] { (Compiling)[Pipeline] sh+ python3 -u ci-tooling/helpers/compile-build.py --product Frameworks --project knotifications --branchGroup kf5-qt5 --platform AndroidQt5.11 --usingInstall /home/user/install-prefix/Scanning dependencies of target gradleScanning dependencies of target KF5Notifications_autogen[ 10%] Generating gradle/gradlew[ 10%] Automatic MOC for target KF5Notifications[ 10%] Built target gradleScanning dependencies of target knotifications_aar[ 15%] Generating gradle_build/KF5Notifications/build/outputs/aar/KF5Notifications-debug.aar[ 15%] Built target KF5Notifications_autogen[ 20%] Automatic RCC for knotifications.qrcScanning dependencies of target KF5Notifications[ 25%] Building CXX object src/CMakeFiles/KF5Notifications.dir/knotification.cpp.o[ 30%] Building CXX object src/CMakeFiles/KF5Notifications.dir/knotificationmanager.cpp.o[ 40%] Building CXX object src/CMakeFiles/KF5Notifications.dir/kpassivepopup.cpp.o[ 40%] Building CXX object src/CMakeFiles/KF5Notifications.dir/knotifyconfig.cpp.o[ 45%] Building CXX object src/CMakeFiles/KF5Notifications.dir/knotificationplugin.cpp.o[ 50%] Building CXX object src/CMakeFiles/KF5Notifications.dir/notifybypopupgrowl.cpp.o[ 55%] Building CXX object src/CMakeFiles/KF5Notifications.dir/notifybyexecute.cpp.oStarting a Gradle Daemon, 1 incompatible and 1 stopped Daemons could not be reused, use --status for details[ 60%] Building CXX object src/CMakeFiles/KF5Notifications.dir/notifybylogfile.cpp.o[ 65%] Building CXX object src/CMakeFiles/KF5Notifications.dir/notifybytaskbar.cpp.o[ 70%] Building CXX object src/CMakeFiles/KF5Notifications.dir/ECMQmLoader-knotifications5_qt.cpp.o[ 75%] Building CXX object src/CMakeFiles/KF5Notifications.dir/notifybyandroid.cpp.o[ 80%] Building CXX object src/CMakeFiles/KF5Notifications.dir/debug_p.cpp.o[ 85%] Building CXX object src/CMakeFiles/KF5Notifications.dir/notifybytts.cpp.o[ 90%] Building CXX object src/CMakeFiles/KF5Notifications.dir/KF5Notifications_autogen/mocs_compilation.cpp.o[ 95%] Building CXX object src/CMakeFiles/KF5Notifications.dir/KF5Notifications_autogen/EWIEGA46WW/qrc_knotifications.cpp.o[100%] Linking CXX shared library ../bin/libKF5Notifications.so[100%] Built target KF5NotificationsFAILURE: Build failed with an exception.* Where:Build file '/home/user/workspace/Frameworks/knotifications/kf5-qt5 AndroidQt5.11/build/src/android/gradle_build/KF5Notifications/build.gradle' line: 3* What went wrong:A problem occurred evaluating root project 'KF5Notifications'.> Could not find method google() for arguments [] on repository container of type org.gradle.api.internal.artifacts.dsl.DefaultRepositoryHandler.* Try:Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.BUILD FAILEDTotal time: 9.958 secssrc/android/CMakeFiles/knotifications_aar.dir/build.make:65: recipe for target 'src/android/gradle_build/KF5Notifications/build/outputs/aar/KF5Notifications-debug.aar' failedmake[2]: *** [src/android/gradle_build/KF5Notifications/build/outputs/aar/KF5Notifications-debug.aar] Error 1CMakeFiles/Makefile2:276: recipe for target 'src/android/CMakeFiles/knotifications_aar.dir/all' failedmake[1]: *** [src/android/CMakeFiles/knotifications_aar.dir/all] Error 2Makefile:140: recipe for target 'all' failedmake: *** [all] Error 2[Pipeline] }[Pipeline] // stage[Pipeline] }ERROR: script returned 

D18527: List Android as officially supported

[Volker Krause]

vkrause added a comment.


  In D18527#400726 , @bcooksley 
wrote:
  
  > If the following could be corrected before this is landed that would be 
appreciated:
  >  
https://build.kde.org/view/Failing/job/Frameworks/job/knotifications/job/kf5-qt5%20AndroidQt5.11/14/console
  
  
  Yep, D18173  fixes that.

REPOSITORY
  R289 KNotifications

BRANCH
  master

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

To: vkrause, lbeltrame, apol
Cc: bcooksley, kde-frameworks-devel, michaelh, ngraham, bruns

D18563: Don't allow '/' in new directory's name

[Shubham]

shubham retitled this revision from "Don' allow '/' in new directory's name" to 
"Don't allow '/' in new directory's name".

REPOSITORY
  R241 KIO

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

To: shubham, ngraham
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D18563: Don' allow '/' in new directory's name

[Shubham]

shubham edited the summary of this revision.

REPOSITORY
  R241 KIO

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

To: shubham, ngraham
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D18563: Don' allow '/' in new directory's name

[Shubham]

shubham created this revision.
shubham added a reviewer: ngraham.
Herald added a project: Frameworks.
Herald added a subscriber: kde-frameworks-devel.
shubham requested review of this revision.

REVISION SUMMARY
  UNIX system does not support '/' in any valid identifier name, but for 
Windows its opposite.

TEST PLAN
  1. Create new directory named a/b/c
  2. Inline error message appears saying "Unable to create directory named 
a/b/c"

REPOSITORY
  R241 KIO

BRANCH
  master

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

AFFECTED FILES
  src/filewidgets/knewfilemenu.cpp

To: shubham, ngraham
Cc: kde-frameworks-devel, michaelh, ngraham, bruns