date:20141118

Re: Review Request 121173: Use correct version in kbuildsycoca5 executable

2014-11-18 Thread Aleix Pol Gonzalez


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121173/#review70632
---

Ship it!


Ship It!

- Aleix Pol Gonzalez


On Nov. 18, 2014, 11:36 p.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121173/
> ---
> 
> (Updated Nov. 18, 2014, 11:36 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kservice
> 
> 
> Description
> ---
> 
> Use correct version in kbuildsycoca5 executable
> 
> 
> Diffs
> -
> 
>   src/kbuildsycoca/kbuildsycoca.cpp 69b142745863218169d7da5a048293d6ab6b1978 
> 
> Diff: https://git.reviewboard.kde.org/r/121173/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kevin Funk
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 121173: Use correct version in kbuildsycoca5 executable

2014-11-18 Thread Kevin Funk


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121173/
---

Review request for KDE Frameworks.


Repository: kservice


Description
---

Use correct version in kbuildsycoca5 executable


Diffs
-

  src/kbuildsycoca/kbuildsycoca.cpp 69b142745863218169d7da5a048293d6ab6b1978 

Diff: https://git.reviewboard.kde.org/r/121173/diff/


Testing
---


Thanks,

Kevin Funk

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 121047: KCodecs: add MIME codecs, improve {encode, decode}RFC2047String()

2014-11-18 Thread David Faure


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121047/#review70616
---

Ship it!



src/kcodecs.h


Passing a bool to qFatal() isn't supported.

if (!codec) {
qFatal() << "no base64 codec found";
}

or just Q_ASSERT(codec);



src/kcodecs.h


same



src/kcodecs.h


same



src/kcodecs.h


should be private, maybe? or is it used by subclasses?



src/kcodecs.cpp


Sounds like we should at least add a "TODO KF6: remove bool insertLFs", if 
it's useless?

The alternative is to do it now: overload the method (1 arg, 2 args), and 
deprecate the 2 args one.

(either of these can be done in a separate commit, anyhow)


- David Faure


On Nov. 18, 2014, 1:31 p.m., Daniel Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121047/
> ---
> 
> (Updated Nov. 18, 2014, 1:31 p.m.)
> 
> 
> Review request for KDE Frameworks, KDEPIM-Libraries and David Faure.
> 
> 
> Repository: kcodecs
> 
> 
> Description
> ---
> 
> KCodecs currently provides only decodeRFC2047String(), and even that has a 
> comment saying "more robust implementation available in KMime". This patch 
> makes KCodecs::decodeRFC2047String() use the "more robust" implementation 
> from KMime, and adds KCodecs::encodeRFC2047String() counterpart - also using 
> implementation from KMime.
> 
> Since KMime also provides codecs implementing various MIME encodings 
> (quoted-printable, base64, uuencode), and the KMmime implementation of 
> decodeRFC2047String() depends on them, I also brought over all the MIME 
> codecs, and make use of them in all the KCodecs static methods. I believe 
> that having a proper and more robust implementation available in a more 
> generic framework like KCodecs is better, than if it was hidden in the KMime 
> framework. As a result, we can make KMime framework to use KCodecs (it 
> already depends on it anyway) for all the encodings, and only leave classes 
> for storing and parsing the "high-level" message/rfc822 messages, and 
> headers. It also reduces code duplication, and makes all applications use the 
> same encode/decode implementations (which is cool, right? :-))
> 
> The main reason for this move is that I'm trying to move over to KCodecs one 
> small class from KPimUtils framework in kdepimlibs (which is our universal 
> dumping ground in kdepimlibs that I'm trying to get rid of) for generic email 
> address validation, but it depends on proper implementations of 
> encode/decodeRFC2047String methods, so I ended up moving all this stuff :-) 
> The tiny Email class is not part of this review though, I'll wait for this to 
> get in, then post another review. I believe that this is a rather useful tool 
> that could find wide adoption outside PIM, therefor I decided not to move it 
> from KPimUtils to KMime, but instead move all the interesting, and 
> multi-purpose parts from KMime into KCodecs.
> 
> I also moved over related KMime unit-tests (that's why the review is so big).
> 
> 
> Diffs
> -
> 
>   autotests/data/codec_x-kmime-rfc2231/basic-encode.expected PRE-CREATION 
>   autotests/data/codec_x-kmime-rfc2231/null-decode.x-kmime-rfc2231 
> PRE-CREATION 
>   autotests/data/codec_x-kmime-rfc2231/null-decode.x-kmime-rfc2231.expected 
> PRE-CREATION 
>   autotests/data/codec_x-kmime-rfc2231/null-encode PRE-CREATION 
>   autotests/data/codec_x-kmime-rfc2231/null-encode.expected PRE-CREATION 
>   autotests/data/codec_x-uuencode/basic-decode.x-uuencode PRE-CREATION 
>   autotests/data/codec_x-uuencode/basic-decode.x-uuencode.expected 
> PRE-CREATION 
>   autotests/kcodecstest.h PRE-CREATION 
>   autotests/kcodecstest.cpp PRE-CREATION 
>   autotests/rfc2047test.h PRE-CREATION 
>   autotests/rfc2047test.cpp PRE-CREATION 
>   src/CMakeLists.txt adc0f2a 
>   src/kcodecs.h 48effbb 
>   src/kcodecs.cpp 4fd660d 
>   src/kcodecs_p.h PRE-CREATION 
>   src/kcodecsbase64.h PRE-CREATION 
>   src/kcodecsbase64.cpp PRE-CREATION 
>   src/kcodecsidentity.h PRE-CREATION 
>   src/kcodecsidentity.cpp PRE-CREATION 
>   src/kcodecsqp.h PRE-CREATION 
>   src/kcodecsqp.cpp PRE-CREATION 
>   src/kcodecsuuencode.h PRE-CREATION 
>   src/kcodecsuuencode.cpp PRE-CREATION 
>   autotests/CMakeLists.txt 4c41ba2 
>   autotests/base64benchmark.cpp PRE-CREATION 
>   autotests/codectest.h PRE-CREATION 
>   autotests/codectest.cpp PRE-CREATION 
>   autotests/data/co

Review Request 121172: Move libgit2-related macro defs into config.h

2014-11-18 Thread Kevin Funk


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121172/
---

Review request for KDE Frameworks and Christoph Cullmann.


Repository: ktexteditor


Description
---

Only recompile dependent files in case of dep changes


Diffs
-

  CMakeLists.txt 5a597818e8b5a16899c10fd4a460e09bb233 
  config.h.cmake e1c9f34cf24eb516c540db3288c93ad5bd093df3 
  src/document/katedocument.cpp aac17c719cbabf78c2135062fe566671713cea02 
  src/utils/kateglobal.cpp 473240514eaeb7f108a5bc0a06e182d4aacc7a80 

Diff: https://git.reviewboard.kde.org/r/121172/diff/


Testing
---


Thanks,

Kevin Funk

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 120760: Fix bug #340212: incorrect soft-tabs alignment after beginning-of-line

2014-11-18 Thread Michael Hansen


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120760/
---

(Updated Nov. 18, 2014, 6:55 p.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks and Christoph Cullmann.


Repository: ktexteditor


Description
---

Fix for incorrect soft-tabs alignment after beginning-of-line, by taking the 
current cursor position into account when expanding tabs to spaces.

This also now uses the indentation width rather than the tab width, as I see 
"Tab Width" as being the actual width of the \t character, and "Indentation 
width" as being the next alignment position for virtual indentation.  This more 
closely matches other editors (e.g. vim) which have similar indentation control.


Diffs
-

  src/document/katedocument.h 8e93f7a9940c98324236f1269d25ccf98d04f968 
  src/document/katedocument.cpp 9a809fad5fe879f11402cf9d274b3463cb267d66 

Diff: https://git.reviewboard.kde.org/r/120760/diff/


Testing
---

Typed the testcase in bug 340212 with various indent/tab width settings.  Only 
Soft Tab mode is affected by this change.

With Indent 4/Tab 4:
int x;
string  y;
boolz;

With Indent 4/Tab 8:
int x;
string  y;
boolz;

With Indent 8/Tab 8 (single [tab] on the first line):
int x;
string  y;
boolz;


Thanks,

Michael Hansen

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 121113: Use Qt's method of blocking for component completion rather than our own

2014-11-18 Thread Marco Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121113/#review70598
---

Ship it!


Ship It!

- Marco Martin


On Nov. 13, 2014, 6:24 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121113/
> ---
> 
> (Updated Nov. 13, 2014, 6:24 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: kdeclarative
> 
> 
> Description
> ---
> 
> We had a while loop which processed all application events whilst we
> were in the middle of creating objects. This leads to weird bugs, and
> workarounds in ShellCorona.
> 
> Qt's methods forceCompletion does not seem to have the same problems and
> works just as well.
> 
> 
> Diffs
> -
> 
>   src/kdeclarative/qmlobject.cpp 029edaf 
> 
> Diff: https://git.reviewboard.kde.org/r/121113/diff/
> 
> 
> Testing
> ---
> 
> Ran plasmashell with many panels filled with applets
> 
> Added debug on void ShellCorona::createWaitingPanels() to make sure it was 
> never called with m_loading true.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 121086: Rename jpegcreatorsettings.kcfg to avoid conflicts with KDE4

2014-11-18 Thread Sebastian Kügler


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121086/#review70583
---



thumbnail/CMakeLists.txt


whitespace


What I'm missing is migration of the setting, is that relevant, any other 
reason why it's missing?

- Sebastian Kügler


On Nov. 9, 2014, 4:09 p.m., Armin K. wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121086/
> ---
> 
> (Updated Nov. 9, 2014, 4:09 p.m.)
> 
> 
> Review request for KDE Runtime, KDE Frameworks and Plasma.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> Simply add 5 as a suffix to avoid conflicts with KDE 4 version which
> is shipped in KDE-Runtime which isn't going away any time now.
> 
> 
> Diffs
> -
> 
>   thumbnail/CMakeLists.txt e9ab79b 
>   thumbnail/jpegcreator.cpp de4902b 
>   thumbnail/jpegcreatorsettings.kcfg 8f68f46 
>   thumbnail/jpegcreatorsettings.kcfgc 3f6cdab 
>   thumbnail/jpegcreatorsettings5.kcfg PRE-CREATION 
>   thumbnail/jpegcreatorsettings5.kcfgc PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/121086/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Armin K.
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 120155: Correctly load non-square icons in KIconLoader

2014-11-18 Thread Daniel Vrátil


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120155/
---

(Updated Nov. 18, 2014, 2:38 p.m.)


Status
--

This change has been discarded.


Review request for KDE Frameworks and Christoph Feck.


Repository: kiconthemes


Description
---

KIconLoader (and KIconTheme) were always using single int to specify icon size, 
which implies only square icons. When requesting non-square icons however (such 
as pixmap sequence animations), the returned QPixmap is deformed. This patch 
ports all internals of KIconLoader to QSize.


Diffs
-

  src/kiconengine.cpp 530403e 
  src/kiconloader.h 46d3017 
  src/kiconloader.cpp 2587b46 
  src/kicontheme.h ca04879 
  src/kicontheme.cpp 4f0e522 

Diff: https://git.reviewboard.kde.org/r/120155/diff/


Testing
---

QIcon icon = QIcon::fromTheme(QLatin1String("process-working"));
QPixmap pix = icon.pixmap(22, 8 * 22);

With this patch, the pix looks as expected.


Thanks,

Daniel Vrátil

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 121094: KCoreAddons: add KTextToHTML class for plaintext -> HTML conversion

2014-11-18 Thread Daniel Vrátil


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121094/
---

(Updated Nov. 18, 2014, 2:37 p.m.)


Review request for KDE Frameworks and Michael Pyne.


Repository: kcoreaddons


Description
---

This class comes from KPimUtils::LinkLocator from kdepimlibs.git. This class 
takes plaintext string, and converts it to HTML while perserving spacing, 
converting URLs and email addresses into  links and interpreting 
highligting markup (*bold*, _underline_, /italic/) and wrapping it to 
corresponding HTML tags. It can also convert text emoticons into  smileys.

The last - emoticons conversion - depends on KEmoticons, which we can't use 
directly from KCoreAddons, so I moved the actual KEmoticons code into 
FrameworkIntegration plugin. There is a dummy implementation provided by 
default in KCoreAddons that is loaded when the FrameworkIntegration plugin is 
not available, or when the application is only a QCoreApplication (since 
KEmoticons require QGuiApplication, so we must not load the plugin). The dummy 
implementation does nothing and returns the original string unaltered.

The reason for moving the class from KPimUtils is that KPimUtils is going to 
die, and while we could make this internal to KDE PIM, I think this is a rather 
useful code, that can be used by many applications that need to deal with 3rd 
party text data and want to provide user-friendly clickable links.

If you compare this with the original KPimUtils::LinkLocator you find, that I 
removed all public API except for the convertToHTML method. This is because the 
remaining methods (getUrl, getEmailAddress) depend on the actual state of the 
LinkLocator object, but LinkLocator provides no API for step-by-step parsing, 
so they were actually useless for public use. For that reason I decided to only 
publish the convertToHTML method, and hide the remaining methods as internal 
methods of the KTextToHTMLHelper (useful for unit-testing).

This patch also contains a unit-test from KPimUtils.


Diffs (updated)
-

  autotests/CMakeLists.txt d5a5feb 
  autotests/ktexttohtmltest.h PRE-CREATION 
  autotests/ktexttohtmltest.cpp PRE-CREATION 
  src/lib/CMakeLists.txt 1dc5627 
  src/lib/text/ktexttohtml.h PRE-CREATION 
  src/lib/text/ktexttohtml.cpp PRE-CREATION 
  src/lib/text/ktexttohtml_p.h PRE-CREATION 
  src/lib/text/ktexttohtmlemoticonsinterface.h PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/121094/diff/


Testing
---

Unit test passes


Thanks,

Daniel Vrátil

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 121047: KCodecs: add MIME codecs, improve {encode, decode}RFC2047String()

2014-11-18 Thread Daniel Vrátil


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121047/
---

(Updated Nov. 18, 2014, 2:31 p.m.)


Review request for KDE Frameworks, KDEPIM-Libraries and David Faure.


Repository: kcodecs


Description
---

KCodecs currently provides only decodeRFC2047String(), and even that has a 
comment saying "more robust implementation available in KMime". This patch 
makes KCodecs::decodeRFC2047String() use the "more robust" implementation from 
KMime, and adds KCodecs::encodeRFC2047String() counterpart - also using 
implementation from KMime.

Since KMime also provides codecs implementing various MIME encodings 
(quoted-printable, base64, uuencode), and the KMmime implementation of 
decodeRFC2047String() depends on them, I also brought over all the MIME codecs, 
and make use of them in all the KCodecs static methods. I believe that having a 
proper and more robust implementation available in a more generic framework 
like KCodecs is better, than if it was hidden in the KMime framework. As a 
result, we can make KMime framework to use KCodecs (it already depends on it 
anyway) for all the encodings, and only leave classes for storing and parsing 
the "high-level" message/rfc822 messages, and headers. It also reduces code 
duplication, and makes all applications use the same encode/decode 
implementations (which is cool, right? :-))

The main reason for this move is that I'm trying to move over to KCodecs one 
small class from KPimUtils framework in kdepimlibs (which is our universal 
dumping ground in kdepimlibs that I'm trying to get rid of) for generic email 
address validation, but it depends on proper implementations of 
encode/decodeRFC2047String methods, so I ended up moving all this stuff :-) The 
tiny Email class is not part of this review though, I'll wait for this to get 
in, then post another review. I believe that this is a rather useful tool that 
could find wide adoption outside PIM, therefor I decided not to move it from 
KPimUtils to KMime, but instead move all the interesting, and multi-purpose 
parts from KMime into KCodecs.

I also moved over related KMime unit-tests (that's why the review is so big).


Diffs (updated)
-

  autotests/data/codec_x-kmime-rfc2231/basic-encode.expected PRE-CREATION 
  autotests/data/codec_x-kmime-rfc2231/null-decode.x-kmime-rfc2231 PRE-CREATION 
  autotests/data/codec_x-kmime-rfc2231/null-decode.x-kmime-rfc2231.expected 
PRE-CREATION 
  autotests/data/codec_x-kmime-rfc2231/null-encode PRE-CREATION 
  autotests/data/codec_x-kmime-rfc2231/null-encode.expected PRE-CREATION 
  autotests/data/codec_x-uuencode/basic-decode.x-uuencode PRE-CREATION 
  autotests/data/codec_x-uuencode/basic-decode.x-uuencode.expected PRE-CREATION 
  autotests/kcodecstest.h PRE-CREATION 
  autotests/kcodecstest.cpp PRE-CREATION 
  autotests/rfc2047test.h PRE-CREATION 
  autotests/rfc2047test.cpp PRE-CREATION 
  src/CMakeLists.txt adc0f2a 
  src/kcodecs.h 48effbb 
  src/kcodecs.cpp 4fd660d 
  src/kcodecs_p.h PRE-CREATION 
  src/kcodecsbase64.h PRE-CREATION 
  src/kcodecsbase64.cpp PRE-CREATION 
  src/kcodecsidentity.h PRE-CREATION 
  src/kcodecsidentity.cpp PRE-CREATION 
  src/kcodecsqp.h PRE-CREATION 
  src/kcodecsqp.cpp PRE-CREATION 
  src/kcodecsuuencode.h PRE-CREATION 
  src/kcodecsuuencode.cpp PRE-CREATION 
  autotests/CMakeLists.txt 4c41ba2 
  autotests/base64benchmark.cpp PRE-CREATION 
  autotests/codectest.h PRE-CREATION 
  autotests/codectest.cpp PRE-CREATION 
  autotests/data/codec_b/basic-decode.b PRE-CREATION 
  autotests/data/codec_b/basic-decode.b.expected PRE-CREATION 
  autotests/data/codec_b/basic-encode PRE-CREATION 
  autotests/data/codec_b/basic-encode.expected PRE-CREATION 
  autotests/data/codec_b/null-decode.b PRE-CREATION 
  autotests/data/codec_b/null-decode.b.expected PRE-CREATION 
  autotests/data/codec_b/null-encode PRE-CREATION 
  autotests/data/codec_b/null-encode.expected PRE-CREATION 
  autotests/data/codec_b/padding0-encode PRE-CREATION 
  autotests/data/codec_b/padding0-encode.expected PRE-CREATION 
  autotests/data/codec_b/padding1-encode PRE-CREATION 
  autotests/data/codec_b/padding1-encode.expected PRE-CREATION 
  autotests/data/codec_b/padding2-encode PRE-CREATION 
  autotests/data/codec_b/padding2-encode.expected PRE-CREATION 
  autotests/data/codec_base64/basic-decode.base64 PRE-CREATION 
  autotests/data/codec_base64/basic-decode.base64.expected PRE-CREATION 
  autotests/data/codec_base64/basic-encode PRE-CREATION 
  autotests/data/codec_base64/basic-encode.expected PRE-CREATION 
  autotests/data/codec_base64/corrupt.base64 PRE-CREATION 
  autotests/data/codec_base64/corrupt.base64.expected PRE-CREATION 
  autotests/data/codec_base64/very_small-encode PRE-CREATION 
  autotests/data/codec_base64/very_small-encode.expected PRE-CREATION 
  autotests/data/codec_q/all-encoded-decode.q PRE-CRE

Re: Review Request 121047: KCodecs: add MIME codecs, improve {encode, decode}RFC2047String()

2014-11-18 Thread Daniel Vrátil



> On Nov. 16, 2014, 10:05 p.m., David Faure wrote:
> > src/kcodecsbase64.h, line 161
> > 
> >
> > What a weird codec name??

Looks weird, but is correct. This is the name of the encoding that appears in 
MIME-encoded strings, like `=?UTF-8?B?herecomessomebase64?=` (RFC2047, Section 
4.1).


- Daniel


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121047/#review70478
---


On Nov. 14, 2014, 1:41 p.m., Daniel Vrátil wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121047/
> ---
> 
> (Updated Nov. 14, 2014, 1:41 p.m.)
> 
> 
> Review request for KDE Frameworks, KDEPIM-Libraries and David Faure.
> 
> 
> Repository: kcodecs
> 
> 
> Description
> ---
> 
> KCodecs currently provides only decodeRFC2047String(), and even that has a 
> comment saying "more robust implementation available in KMime". This patch 
> makes KCodecs::decodeRFC2047String() use the "more robust" implementation 
> from KMime, and adds KCodecs::encodeRFC2047String() counterpart - also using 
> implementation from KMime.
> 
> Since KMime also provides codecs implementing various MIME encodings 
> (quoted-printable, base64, uuencode), and the KMmime implementation of 
> decodeRFC2047String() depends on them, I also brought over all the MIME 
> codecs, and make use of them in all the KCodecs static methods. I believe 
> that having a proper and more robust implementation available in a more 
> generic framework like KCodecs is better, than if it was hidden in the KMime 
> framework. As a result, we can make KMime framework to use KCodecs (it 
> already depends on it anyway) for all the encodings, and only leave classes 
> for storing and parsing the "high-level" message/rfc822 messages, and 
> headers. It also reduces code duplication, and makes all applications use the 
> same encode/decode implementations (which is cool, right? :-))
> 
> The main reason for this move is that I'm trying to move over to KCodecs one 
> small class from KPimUtils framework in kdepimlibs (which is our universal 
> dumping ground in kdepimlibs that I'm trying to get rid of) for generic email 
> address validation, but it depends on proper implementations of 
> encode/decodeRFC2047String methods, so I ended up moving all this stuff :-) 
> The tiny Email class is not part of this review though, I'll wait for this to 
> get in, then post another review. I believe that this is a rather useful tool 
> that could find wide adoption outside PIM, therefor I decided not to move it 
> from KPimUtils to KMime, but instead move all the interesting, and 
> multi-purpose parts from KMime into KCodecs.
> 
> I also moved over related KMime unit-tests (that's why the review is so big).
> 
> 
> Diffs
> -
> 
>   autotests/data/codec_q/all-encoded-decode.q PRE-CREATION 
>   autotests/data/codec_q/all-encoded-decode.q.expected PRE-CREATION 
>   autotests/data/codec_q/basic-encode PRE-CREATION 
>   autotests/data/codec_q/basic-encode.expected PRE-CREATION 
>   autotests/data/codec_q/null-decode.q PRE-CREATION 
>   autotests/data/codec_q/null-decode.q.expected PRE-CREATION 
>   autotests/data/codec_q/null-encode PRE-CREATION 
>   autotests/data/codec_q/null-encode.expected PRE-CREATION 
>   autotests/data/codec_quoted-printable/basic-decode.quoted-printable 
> PRE-CREATION 
>   
> autotests/data/codec_quoted-printable/basic-decode.quoted-printable.expected 
> PRE-CREATION 
>   autotests/data/codec_quoted-printable/basic-encode PRE-CREATION 
>   autotests/data/codec_quoted-printable/basic-encode.expected PRE-CREATION 
>   autotests/data/codec_quoted-printable/corrupt.quoted-printable PRE-CREATION 
>   autotests/data/codec_quoted-printable/corrupt.quoted-printable.expected 
> PRE-CREATION 
>   autotests/data/codec_quoted-printable/corrupt2.quoted-printable 
> PRE-CREATION 
>   autotests/data/codec_quoted-printable/corrupt2.quoted-printable.expected 
> PRE-CREATION 
>   autotests/data/codec_quoted-printable/corrupt3.quoted-printable 
> PRE-CREATION 
>   autotests/data/codec_quoted-printable/corrupt3.quoted-printable.expected 
> PRE-CREATION 
>   autotests/data/codec_quoted-printable/corrupt4.quoted-printable 
> PRE-CREATION 
>   autotests/data/codec_quoted-printable/corrupt4.quoted-printable.expected 
> PRE-CREATION 
>   autotests/data/codec_quoted-printable/wrap-encode PRE-CREATION 
>   autotests/data/codec_quoted-printable/wrap-encode.expected PRE-CREATION 
>   autotests/data/codec_x-kmime-rfc2231/all-encoded.x-kmime-rfc2231-decode 
> PRE-CREATION 
>   
> autotests/data/codec_x-kmime-rfc2231/all-encoded.x-kmime-rfc2231-decode.expected
>  PRE-CREATION 
>   autotests

Re: Review Request 121084: Rename libmolletnetwork to avoid conflict with KDE4

2014-11-18 Thread Sebastian Kügler


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121084/#review70581
---

Ship it!


Looks sane to me, also solves a real-world problem. Thanks!

- Sebastian Kügler


On Nov. 9, 2014, 4:10 p.m., Armin K. wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121084/
> ---
> 
> (Updated Nov. 9, 2014, 4:10 p.m.)
> 
> 
> Review request for KDE Runtime, KDE Frameworks and Plasma.
> 
> 
> Repository: kio-extras
> 
> 
> Description
> ---
> 
> KDE-Runtime already provides libmolletnetwork, so lets rename
> this one to include 5 as a suffix since many apps outside of
> KDE still depend on KDE-Runtime.
> 
> 
> Diffs
> -
> 
>   network/ioslave/CMakeLists.txt 06a964d 
>   network/kded/CMakeLists.txt 3be676e 
>   network/network/CMakeLists.txt c0fb43e 
> 
> Diff: https://git.reviewboard.kde.org/r/121084/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Armin K.
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 121145: A button which appears on the side of a splitter handle and allows easy collapsing of the widget on the opposite side

2014-11-18 Thread Laurent Montel


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121145/
---

(Updated Nov. 18, 2014, 11:23 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, Christoph Feck and David Faure.


Repository: kwidgetsaddons


Description
---

This new widget adds a button on splitter to collapse it.


Diffs
-

  src/ksplittercollapserbutton.h PRE-CREATION 
  src/ksplittercollapserbutton.cpp PRE-CREATION 
  tests/CMakeLists.txt 5086ac0 
  tests/ksplittercollapserbuttongui_test.h PRE-CREATION 
  tests/ksplittercollapserbuttongui_test.cpp PRE-CREATION 
  autotests/CMakeLists.txt 26c479f 
  autotests/ksplittercollapserbuttontest.h PRE-CREATION 
  autotests/ksplittercollapserbuttontest.cpp PRE-CREATION 
  src/CMakeLists.txt 059d5d9 

Diff: https://git.reviewboard.kde.org/r/121145/diff/


Testing
---

Created a lot of unittest.

I already done a lot of review code with David (thanks).

This widget can be show in kmail->compositor->snipset for example (in 4.14).


Thanks,

Laurent Montel

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 121145: A button which appears on the side of a splitter handle and allows easy collapsing of the widget on the opposite side

2014-11-18 Thread Christoph Feck


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121145/#review70575
---

Ship it!


Ship It!

- Christoph Feck


On Nov. 17, 2014, 4:48 p.m., Laurent Montel wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121145/
> ---
> 
> (Updated Nov. 17, 2014, 4:48 p.m.)
> 
> 
> Review request for KDE Frameworks, Christoph Feck and David Faure.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> This new widget adds a button on splitter to collapse it.
> 
> 
> Diffs
> -
> 
>   src/ksplittercollapserbutton.h PRE-CREATION 
>   src/ksplittercollapserbutton.cpp PRE-CREATION 
>   tests/CMakeLists.txt 5086ac0 
>   tests/ksplittercollapserbuttongui_test.h PRE-CREATION 
>   tests/ksplittercollapserbuttongui_test.cpp PRE-CREATION 
>   autotests/CMakeLists.txt 26c479f 
>   autotests/ksplittercollapserbuttontest.h PRE-CREATION 
>   autotests/ksplittercollapserbuttontest.cpp PRE-CREATION 
>   src/CMakeLists.txt 059d5d9 
> 
> Diff: https://git.reviewboard.kde.org/r/121145/diff/
> 
> 
> Testing
> ---
> 
> Created a lot of unittest.
> 
> I already done a lot of review code with David (thanks).
> 
> This widget can be show in kmail->compositor->snipset for example (in 4.14).
> 
> 
> Thanks,
> 
> Laurent Montel
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 121153: Restore filedialog show() functionality for modal dialogs

2014-11-18 Thread Martin Klapetek



> On Nov. 18, 2014, 12:33 a.m., Jeremy Whiting wrote:
> > I tested this here and FileDialog qml still hangs the ui with this patch. 
> > (though at least the dialog appears)

Yes, QML still hangs, not sure why though. Looking into it.


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121153/#review70564
---


On Nov. 17, 2014, 6:46 p.m., Martin Klapetek wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/121153/
> ---
> 
> (Updated Nov. 17, 2014, 6:46 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> Based on https://git.reviewboard.kde.org/r/121098/ and on the GTK2 platform 
> theme, which does the modal show() like this.
> 
> 
> Diffs
> -
> 
>   src/platformtheme/kdeplatformfiledialoghelper.cpp 44eca19 
> 
> Diff: https://git.reviewboard.kde.org/r/121153/diff/
> 
> 
> Testing
> ---
> 
> All kinds of file dialogs from tests/qfiledialogtest work as expected
> 
> 
> Thanks,
> 
> Martin Klapetek
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 121173: Use correct version in kbuildsycoca5 executable

Review Request 121173: Use correct version in kbuildsycoca5 executable

Re: Review Request 121047: KCodecs: add MIME codecs, improve {encode, decode}RFC2047String()

Review Request 121172: Move libgit2-related macro defs into config.h

Re: Review Request 120760: Fix bug #340212: incorrect soft-tabs alignment after beginning-of-line

Re: Review Request 121113: Use Qt's method of blocking for component completion rather than our own

Re: Review Request 121086: Rename jpegcreatorsettings.kcfg to avoid conflicts with KDE4

Re: Review Request 120155: Correctly load non-square icons in KIconLoader

Re: Review Request 121094: KCoreAddons: add KTextToHTML class for plaintext -> HTML conversion

Re: Review Request 121047: KCodecs: add MIME codecs, improve {encode, decode}RFC2047String()

Re: Review Request 121047: KCodecs: add MIME codecs, improve {encode, decode}RFC2047String()

Re: Review Request 121084: Rename libmolletnetwork to avoid conflict with KDE4

Re: Review Request 121145: A button which appears on the side of a splitter handle and allows easy collapsing of the widget on the opposite side

Re: Review Request 121145: A button which appears on the side of a splitter handle and allows easy collapsing of the widget on the opposite side

Re: Review Request 121153: Restore filedialog show() functionality for modal dialogs

15 matches

Site Navigation

Mail list logo

Footer information