Re: Notifications-future, a recap

2012-09-20 Thread Dario Freddi 
2012/9/20 Sune Vuorela :
> On 2012-09-17, Dario Freddi  wrote:
>> It really depends on what you want to achieve. If your goal is just
>> cleaning up the API and implementing the existing standard it might
>> work out, but for sure it won't just cut it for what I proposed, where
>
> Why won't the existing (as in the fdo/galago spec) api cut it to ensure
> we also play well with others (in both directions) ?

Wait. Noone ever said we wouldn't be compatible with the existing spec
back and forth, quite the opposite. I just said I'd try to push our
changes upstream, this doesn't mean we wouldn't be compatible with
fdo, it would be a suicide. The current API simply WON'T ALLOW
applications with specific requirements to take advantage of a more
fine-grained system. More below.

> Really. All I read is complexity for teh sake of complexity, trying
> to build walled gardens for the sake of building walled gardens and
> complicating deployment for the sake of complicating deployment.
> And I don't think that's neither modern, slick nor futureproof.

I am sorry, but no. If you read my second post it is blatant clear
we're lagging behind every possible modern concept of notifications.
Example: has Akonadi or any other data-intensive application ever
failed on you? It does to me quite often, and I get 30 error spam
bubbles my system simply can't handle and drive me mad every time. And
what about losing track of incoming mails/messages? Thank god Kubuntu
kind of implements support for persistent notifications, otherwise I'd
lose every single time people ping me on IRC.

If we want to pretend what we have is already enough, we can live in
our own small world. But looking outside of our bubble should tell us
something, and making us realize we have to try to walk a step
forward. Complexity in the server code leads to simplicity to the user
and to developers - most of the features I have disclosed won't be
exposed through the API - as I explained, most of the grouping can be
done with the current means we have. On the client (applet) side,
everything would be much easier since the applet would just receive a
model. It really can't get simpler than that.

A more complex API will be provided to those application which have
specific needs, such as contact list. Your average (80%) application
will just benefit from SC and won't even notice. You don't want to
make your application a handler? Fine, still works. You don't need to
associate a specific event to an activity? Fine, still works, and
moreover the API will figure this out for you. I really cannot see how
this would get more complex to users and developers. Of course it is
more complicated than what we have now INTERNALLY, but again you
should look at the benefits.

If the majority doesn't want this, I won't be the one pushing it, but
stating that such a change isn't a step towards being more modern is
willingfully ignoring everything outside KDE - I didn't write 3 blog
posts for anything, and my first two ones were exactly aimed at
answering concerns like yours. Seriously, the only "new" thing in that
concept, in complete honesty, is the activity integration - everything
else can be found in any modern interface, be it phone, desktop or
web.

>
> /Sune
>
> ___
> Plasma-devel mailing list
> plasma-de...@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request: Port some uses of KProcess to QProcess

2012-09-20 Thread Oswald Buddenhagen 


> On Sept. 19, 2012, 5:11 p.m., Oswald Buddenhagen wrote:
> > every single change of this patch is a regression
> 
> David Faure wrote:
> Very encouraging, as always. Care to give us more details?
> 
> Oswald Buddenhagen wrote:
> the reasons for kprocess' existence didn't go away, so every change away 
> from it is by definition a regression, either in functionality or 
> maintainablity. and the consistent replacement of setOutputChannelMode() with 
> setReadChannel() is so bizarre that one has to wonder what i wrote the apidoc 
> for in the first place.
> 
> in case somebody is interested, i still have the (rather unfinished) 
> qprocess patches i wrote five years ago to address (some of) the issues 
> upstream. it would be qt 5.1 material, obviously.
> 
> David Faure wrote:
> That reasoning assumes that we need the additional-features-in-KProcess 
> everywhere KProcess is used, which is just not the case.
> 
> See commits ed71a84ca2178865d947169a8f35a025c708a2ef and 
> 66fda6d3faafeadac82eae6b8308787b3fe96911 which already ported some KProcess 
> to QProcess, and which did not introduce regressions (most are in unittests, 
> which still pass).
> 
> You're right about setOutputChannelMode, though -- apparently the proper 
> replacement is QProcess::setProcessChannelMode.
> 
> Still I don't see why we can't use QProcess in its current form... like 
> everything it could be improved, but surely all other Qt apps manage just 
> fine?

ed71a84ca2178 is arguably broken.

yes. a rather suboptimal replacement. before you ask, search the core-devel 
archive shortly before the time the new kprocess was added.

other apps managed with motif just fine, too. doesn't mean the users liked the 
outcome.


- Oswald


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106500/#review19174
---


On Sept. 18, 2012, 11:12 p.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106500/
> ---
> 
> (Updated Sept. 18, 2012, 11:12 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Port some uses of KProcess to QProcess
> 
> 
> Diffs
> -
> 
>   kdeui/dialogs/kedittoolbar.cpp 0582934b0bf8cb7160cb48b4c8151c81b35277f0 
>   kinit/klauncher.cpp 855e56041be5a5b76b9a7e9d0597ac7ad485682e 
>   kio/kfile/kfilemetadatareader.cpp 88cadaa2edf1b1de24c0e91576cca368db41f470 
>   kio/kio/krun.h 7bfe66b59f1deffc37d3ceae999fb929e453fd31 
>   kio/kio/krun.cpp 031dbc1dfef685729038b4a59cbeacd34d448ed2 
>   kio/kio/krun_p.h 0ad15c8434599ccabcd649f251aa622d4fb0b0f7 
>   staging/kwidgets/autotests/kglobalsettingstest.cpp 
> 4426fee08427499c777cc7fc94e4b1345c790ac2 
> 
> Diff: http://git.reviewboard.kde.org/r/106500/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: remove FindLibLZMA.cmake from karchive framework

2012-09-20 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105866/#review19248
---

Ship it!


cmake 2.8.9 has been released now, please commit.

- David Faure


On Aug. 5, 2012, 9:43 a.m., George Goldberg wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105866/
> ---
> 
> (Updated Aug. 5, 2012, 9:43 a.m.)
> 
> 
> Review request for KDE Frameworks, Mario Bensi and David Faure.
> 
> 
> Description
> ---
> 
> CMake now appears to ship with an equivalent, which worked fine for me 
> building the karchive framework.
> 
> 
> Diffs
> -
> 
>   tier1/karchive/cmake/FindLibLZMA.cmake 
> 1a341b28effa9a54d6e27c4e7f3704f3473921e8 
> 
> Diff: http://git.reviewboard.kde.org/r/105866/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> George Goldberg
> 
>

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

Re: Review Request: KF5 - Q_OS_* not defined

2012-09-20 Thread David Faure 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/105868/#review19247
---

Ship it!


Please commit, the current stuff (Q_OS in CMakeLists.txt) is just wrong :)

- David Faure


On Aug. 5, 2012, 10:28 p.m., Andrius da Costa Ribas wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/105868/
> ---
> 
> (Updated Aug. 5, 2012, 10:28 p.m.)
> 
> 
> Review request for KDE Frameworks and kdewin.
> 
> 
> Description
> ---
> 
> Q_OS_WIN & Q_OS_MAC not defined at that point, replacing with WIN32 and APPLE.
> 
> 
> Diffs
> -
> 
>   kde3support/KDE3SupportMacros.cmake a4f44e2 
>   kdecore/CMakeLists.txt e5cbd19 
>   kded/CMakeLists.txt fb204e8 
>   kdeui/CMakeLists.txt 7849b52 
>   kdeui/KDEUIMacros.cmake d5c20d9 
>   kinit/CMakeLists.txt 3c283a6 
>   tier1/kidletime/src/CMakeLists.txt 973d623 
>   tier1/kwindowsystem/src/CMakeLists.txt 96cb3dd 
> 
> Diff: http://git.reviewboard.kde.org/r/105868/diff/
> 
> 
> Testing
> ---
> 
> Got undefined references before the fix.
> 
> 
> Thanks,
> 
> Andrius da Costa Ribas
> 
>

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

Re: Review Request: Port some uses of KProcess to QProcess

2012-09-20 Thread David Faure 


> On Sept. 19, 2012, 5:11 p.m., Oswald Buddenhagen wrote:
> > every single change of this patch is a regression
> 
> David Faure wrote:
> Very encouraging, as always. Care to give us more details?
> 
> Oswald Buddenhagen wrote:
> the reasons for kprocess' existence didn't go away, so every change away 
> from it is by definition a regression, either in functionality or 
> maintainablity. and the consistent replacement of setOutputChannelMode() with 
> setReadChannel() is so bizarre that one has to wonder what i wrote the apidoc 
> for in the first place.
> 
> in case somebody is interested, i still have the (rather unfinished) 
> qprocess patches i wrote five years ago to address (some of) the issues 
> upstream. it would be qt 5.1 material, obviously.

That reasoning assumes that we need the additional-features-in-KProcess 
everywhere KProcess is used, which is just not the case.

See commits ed71a84ca2178865d947169a8f35a025c708a2ef and 
66fda6d3faafeadac82eae6b8308787b3fe96911 which already ported some KProcess to 
QProcess, and which did not introduce regressions (most are in unittests, which 
still pass).

You're right about setOutputChannelMode, though -- apparently the proper 
replacement is QProcess::setProcessChannelMode.

Still I don't see why we can't use QProcess in its current form... like 
everything it could be improved, but surely all other Qt apps manage just fine?


- David


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106500/#review19174
---


On Sept. 18, 2012, 11:12 p.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106500/
> ---
> 
> (Updated Sept. 18, 2012, 11:12 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Port some uses of KProcess to QProcess
> 
> 
> Diffs
> -
> 
>   kdeui/dialogs/kedittoolbar.cpp 0582934b0bf8cb7160cb48b4c8151c81b35277f0 
>   kinit/klauncher.cpp 855e56041be5a5b76b9a7e9d0597ac7ad485682e 
>   kio/kfile/kfilemetadatareader.cpp 88cadaa2edf1b1de24c0e91576cca368db41f470 
>   kio/kio/krun.h 7bfe66b59f1deffc37d3ceae999fb929e453fd31 
>   kio/kio/krun.cpp 031dbc1dfef685729038b4a59cbeacd34d448ed2 
>   kio/kio/krun_p.h 0ad15c8434599ccabcd649f251aa622d4fb0b0f7 
>   staging/kwidgets/autotests/kglobalsettingstest.cpp 
> 4426fee08427499c777cc7fc94e4b1345c790ac2 
> 
> Diff: http://git.reviewboard.kde.org/r/106500/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: Port some uses of KUrl to QUrl

2012-09-20 Thread Oswald Buddenhagen 

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106501/#review19241
---



kio/tests/krununittest.cpp


this whole hunk doesn't belong into this patch at all. one part of it 
belongs into the kprocess patch, the other (the kdesuExe part) is a commit of 
its own.


- Oswald Buddenhagen


On Sept. 19, 2012, 10:19 p.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106501/
> ---
> 
> (Updated Sept. 19, 2012, 10:19 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Port some uses of KUrl to QUrl
> 
> 
> kio: Cleanup header a bit
> 
> 
> kio: Merge some functions using default arguments
> 
> 
> kio: Mark test with QSKIP_PORTING
> 
> 
> Diffs
> -
> 
>   kio/kio/krun.h 7bfe66b59f1deffc37d3ceae999fb929e453fd31 
>   kio/kio/krun.cpp 031dbc1dfef685729038b4a59cbeacd34d448ed2 
>   kio/tests/kruntest.h 6f5eae6147e2fbef25025976a17869af4d0f12f9 
>   kio/tests/kruntest.cpp 92496bd1d4b98ea8f7dc13977cd3d2aa0dae7145 
>   kio/tests/krununittest.cpp 314da79b9ee4f95bcc9f768a95810f7de3125ac1 
> 
> Diff: http://git.reviewboard.kde.org/r/106501/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: Port some uses of KProcess to QProcess

2012-09-20 Thread Oswald Buddenhagen 


> On Sept. 19, 2012, 5:11 p.m., Oswald Buddenhagen wrote:
> > every single change of this patch is a regression
> 
> David Faure wrote:
> Very encouraging, as always. Care to give us more details?

the reasons for kprocess' existence didn't go away, so every change away from 
it is by definition a regression, either in functionality or maintainablity. 
and the consistent replacement of setOutputChannelMode() with setReadChannel() 
is so bizarre that one has to wonder what i wrote the apidoc for in the first 
place.

in case somebody is interested, i still have the (rather unfinished) qprocess 
patches i wrote five years ago to address (some of) the issues upstream. it 
would be qt 5.1 material, obviously.


- Oswald


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/106500/#review19174
---


On Sept. 18, 2012, 11:12 p.m., Kevin Funk wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/106500/
> ---
> 
> (Updated Sept. 18, 2012, 11:12 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Description
> ---
> 
> Port some uses of KProcess to QProcess
> 
> 
> Diffs
> -
> 
>   kdeui/dialogs/kedittoolbar.cpp 0582934b0bf8cb7160cb48b4c8151c81b35277f0 
>   kinit/klauncher.cpp 855e56041be5a5b76b9a7e9d0597ac7ad485682e 
>   kio/kfile/kfilemetadatareader.cpp 88cadaa2edf1b1de24c0e91576cca368db41f470 
>   kio/kio/krun.h 7bfe66b59f1deffc37d3ceae999fb929e453fd31 
>   kio/kio/krun.cpp 031dbc1dfef685729038b4a59cbeacd34d448ed2 
>   kio/kio/krun_p.h 0ad15c8434599ccabcd649f251aa622d4fb0b0f7 
>   staging/kwidgets/autotests/kglobalsettingstest.cpp 
> 4426fee08427499c777cc7fc94e4b1345c790ac2 
> 
> Diff: http://git.reviewboard.kde.org/r/106500/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Kevin Funk
> 
>

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