Re: Submitting Grantlee as a KF5 Framework

[Daniel Nicoletti]

Yes, an user just raised an issue which I fixed in one PR,
however the PR is 5yo, should I redo it in gitlab?
Shouldn't the GitHub repo be removed or marked as moved to KDE?

Em sáb., 21 de dez. de 2019 às 10:23, Friedrich W. H. Kossebau <
kosse...@kde.org> escreveu:

> Hi Stephen,
>
> Am Samstag, 21. Dezember 2019, 13:03:17 CET schrieb Stephen Kelly:
> > Great, Grantlee is now available at g...@git.kde.org:grantlee.git.
> >
> > I've pushed a few commits to make it depend on ECM etc.
>
> You pushed only to github though it seems :) Forwarded your commits now to
> the
> master branch on the main KDE repo. And did some commits to make things
> even
> more (current) KF-like.
>
> Speaking of making sure all is synced & moved from github to KDE systems:
>
> There are still some merge requests open on https://github.com/steveire/
> grantlee/pulls <https://github.com/steveire/grantlee/pulls>. Also are
> there some open issues which might be wanted to be
> moved over to bugs.kde.org?
>
> Cheers
> Friedrich
>
>
>

-- 
Daniel Nicoletti

KDE Developer - http://dantti.wordpress.com

D19035: Help build on Windows with usage of CMake Targets

[Daniel Nicoletti]

dantti added a comment.


  I ended up compiling it using vcpkg toolchain directly on Windows, which 
showed this isn't required.
  
  In fact even when cross-compiling this won't fix anything because the tool 
must run on the host OS.
  
  So I only still think this is useful because the user will notice that it 
tried to compile and run an .EXE which won't work on their host, I don't think 
this will cause any harm but I didn't test if this still works when specifiyng 
the indexer path variable.

REPOSITORY
  R216 Syntax Highlighting

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

To: dantti, #framework_syntax_highlighting, dhaumann, cullmann, vkrause
Cc: kwrite-devel, kde-frameworks-devel, michaelh, ngraham, bruns, demsking, 
cullmann, sars, dhaumann

D19035: Help build on Windows with usage of CMake Targets

[Daniel Nicoletti]

dantti added a comment.


  I'm not entirely sure this is really needed on Windows, but when 
cross-compiling this allowed to search for the katehighlightingindexer.exe 
which wouldn't run because I was on Linux...

REPOSITORY
  R216 Syntax Highlighting

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

To: dantti, #framework_syntax_highlighting, dhaumann, cullmann
Cc: kwrite-devel, kde-frameworks-devel, gennad, michaelh, ngraham, bruns, 
demsking, cullmann, sars, dhaumann

D19035: Help build on Windows with usage of CMake Targets

[Daniel Nicoletti]

dantti created this revision.
dantti added reviewers: Framework: Syntax Highlighting, dhaumann, cullmann.
Herald added projects: Kate, Frameworks.
Herald added subscribers: kde-frameworks-devel, kwrite-devel.
dantti requested review of this revision.

REPOSITORY
  R216 Syntax Highlighting

BRANCH
  master

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

AFFECTED FILES
  data/CMakeLists.txt

To: dantti, #framework_syntax_highlighting, dhaumann, cullmann
Cc: kwrite-devel, kde-frameworks-devel, gennad, michaelh, ngraham, bruns, 
demsking, cullmann, sars, dhaumann

D14006: Fix WebDAV destination header on COPY and MOVE operations

[Daniel Nicoletti]

This revision was automatically updated to reflect the committed changes.
Closed by commit R241:1f24f49baba4: Fix WebDAV destination header on COPY and 
MOVE operations (authored by dantti).

REPOSITORY
  R241 KIO

CHANGES SINCE LAST UPDATE
  https://phabricator.kde.org/D14006?vs=37460=41858

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

AFFECTED FILES
  src/ioslaves/http/http.cpp

To: dantti, dfaure, #frameworks, #dolphin
Cc: bruns, anthonyfieroni, ngraham, kde-frameworks-devel, michaelh

D14006: Fix WebDAV destination header on COPY and MOVE operations

[Daniel Nicoletti]

dantti added a comment.


  Well the issue will probably depend on the server,
  for example Apache2 with Nextcloud it returns forbidden for both operations,
  in Cloudlyst which does:
  QUrl::fromEncoded(QStringLiteral("file:///speçiál").toLatin1()).toLocalFile();
  you get a file with a different file name as URL.
  Since 'ç' is extended ASCII this "fails" only because URL are sopposed
  to use only printable ASCII chars
  
  If you use some some UTF-8 char like ←it wil
  produce that behavior:
  QStringLiteral("spe←ail\r\n").toLatin1()
  will produce:
  "spe?ail\r\n"
  and the question mark is interpreted as being the query part
  of an URL, thus what I said before that it cuts
  everything past the special char due URL parsing.
  you can see doing this:
  
QUrl::fromEncoded(QStringLiteral("file:///file←sadssad").toLatin1()).toLocalFile()
  local file will be "/file"

REPOSITORY
  R241 KIO

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

To: dantti, dfaure, #frameworks, #dolphin
Cc: bruns, anthonyfieroni, ngraham, kde-frameworks-devel, michaelh

D14006: Fix WebDAV destination header on COPY and MOVE operations

[Daniel Nicoletti]

dantti added a comment.


  Test plan:
  
  1. Connecto to a WebDav server
  2. Create a file named "foo"
  3. Try to rename the file to "speçiál" - it should result in "spe"
  
  The COPY operation has the same issue but I'm not sure how to test it right 
now,
  probably it will also fail if the destination directory is named with special 
characters (non-latin1).

REPOSITORY
  R241 KIO

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

To: dantti, dfaure, #frameworks, #dolphin
Cc: bruns, anthonyfieroni, ngraham, kde-frameworks-devel, michaelh

D14006: Fix WebDAV destination header on COPY and MOVE operations

[Daniel Nicoletti]

dantti added a comment.


  Ping? This is a pretty obvious fix, desturl is QString which later becomes 
latin1 loosing characters...

REPOSITORY
  R241 KIO

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

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

D14006: Fix WebDAV destination header on COPY and MOVE operations

[Daniel Nicoletti]

dantti added a comment.


  In D14006#289680 , @ngraham wrote:
  
  > Does this fix any of the bugs here? 
https://bugs.kde.org/buglist.cgi?component=webdav_id=1529637=kio=---
  
  
  Nope, it doesn't fix any of them.

REPOSITORY
  R241 KIO

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

To: dantti, dfaure
Cc: ngraham, kde-frameworks-devel, michaelh, bruns

D14006: Fix WebDAV destination header on COPY and MOVE operations

[Daniel Nicoletti]

dantti added a reviewer: dfaure.

REPOSITORY
  R241 KIO

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

To: dantti, dfaure
Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D14006: Fix WebDAV destination header on COPY and MOVE operations

[Daniel Nicoletti]

dantti created this revision.
Restricted Application added a project: Frameworks.
Restricted Application added a subscriber: kde-frameworks-devel.
dantti requested review of this revision.

REVISION SUMMARY
  The Destination header must always be QUrl::FullyEncoded
  so that special characters can be used as destination.

REPOSITORY
  R241 KIO

BRANCH
  master

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

AFFECTED FILES
  src/ioslaves/http/http.cpp

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

Re: kded5 and kde-workspace

[Daniel Nicoletti]

Funny this is the kind of thing that could just be
avoided if projects stopped using the
org.kde.kded DBus interface and instead registered
their own. I for example don't need to do any change
because I register org.kde.apperd interface so if tomorrow
I decide to use a stand alone approach for the module
it won't break everything calling it.

Maybe it would be a good thing to do that for KDED
modules on 5.

2013/11/21 Àlex Fiestas afies...@kde.org:
 On Wednesday 20 November 2013 20:47:54 Àlex Fiestas wrote:
 Hey there

 Today I have been porting powerdevil and while doing it found out that kded5
 was not loading any modules and many kde-workspace projects were using
 org.kde.kded instead of the one ended with .kded5

 Tomorrow I'd like to push a local commit that changes all org.kde.kded for
 org.kde.kded5 (which we will have to change again but more about that in a
 later email), and will effectively make kde-workspace and plasma-framework
 depend on kded5.

 In order to make kded5 load modules, you have to have KDE_SESSION_VERSION
 set to 5, so add that to your set kde5 environment script.

 So please, adapt your environment asap, I'd like to push this tomorrow so we
 can do testing of the kf5 KDEDModules instead of kded4.

 Cheers !

 Change pushed, please set KDE_SESSION_VERSION to 5 so we can get some testing
 to kded !
 ___
 Plasma-devel mailing list
 plasma-de...@kde.org
 https://mail.kde.org/mailman/listinfo/plasma-devel



-- 
Daniel Nicoletti

KDE Developer - http://dantti.wordpress.com
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel