Review Request: Make kdelibs build against qt 4.8 which has added QStringBuilder to QByteArray + operations.

2011-05-12 Thread Jeremy Paul Whiting

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

Review request for kdelibs and David Faure.


Summary
---

This makes kdelibs build with qt 4.8 (besides the one problem in 
kio/kio/scheduler.cpp).


Diffs
-

  kdecore/io/klockfile_unix.cpp 10c9039 
  kdecore/kernel/kstandarddirs.cpp f5a17aa 
  kdecore/network/k3socks.cpp ed7eed9 
  kdecore/sycoca/ksycocadict.cpp 3df7bce 
  kdeui/kernel/kapplication.cpp 8ec47ca 
  kdeui/tests/kxmlgui_unittest.cpp f19acc0 
  kdeui/tests/proxymodeltestapp/modelcommanderwidget.cpp 2ff9332 
  kdeui/util/kxmessages.cpp 132979d 
  khtml/java/tests/testkjavaappletserver.cpp 454f832 
  plasma/private/serviceprovider_p.h 3ce1ba4 
  plasma/tests/plasmoidpackagetest.cpp 713c400 

Diff: http://git.reviewboard.kde.org/r/101342/diff


Testing
---

Built and installed.  Will build the rest of kde tonight and test in the 
morning.


Thanks,

Jeremy Paul



Re: Review kdelibs whiting/fixQByteArrays

2011-05-12 Thread Jeremy Whiting
Ok, I cleaned this up, redid it basically with the suggestions from this
thread.  I put a review request on reviewboard, and the code is in kdelibs
whiting/buildwithqt48 branch.

Enjoy,
Jeremy

On Mon, May 2, 2011 at 11:37 AM, Olivier Goffart ogoff...@kde.org wrote:

 Le Monday 02 May 2011, David Faure a écrit :

  Another one:
 
  -  envs  QString::fromLatin1( QByteArray(DISPLAY=) + dpystring );
  +envs  QString::fromLatin1( QByteArray(QByteArray(DISPLAY=) +
  dpystring) );

 Should be QLatin1String(DISPLAY=) + QLatin1String(dpystring)
 (Assuming dpystring is char*)


 
  Is this still because QString::fromLatin1( const QByteArray ) is
 missing,
  so it has to cast to const char* here too? Olivier, wouldn't it make
 sense
  to have such an overload? (It would save a strlen, too).

 Yes, maybe  QString::fromLatin1(const QByteArray) would make sens
 But it might brake source compatibility if the call becomes ambiguous.

 The reason why we brake source compatibility with QT_USE_FAST_OPERATOR_PLUS
 is
 because this one was not documented.  But maybe the new operator should
 only
 be enabled if QT_USE_FAST_OPERATOR_PLUS is defined to 2 or something.







Re: Qt5 - KDE5?

2011-05-12 Thread Aaron J. Seigo
On Tuesday, May 10, 2011 17:18:58 Alex Merry wrote:
 On 10/05/11 09:26, Aaron J. Seigo wrote:
  we also have some blighted API that remains that needs cleaning up, but
  we also need to exercise restraint. since we don't need to make huge
  changes to many parts of Platform, we should try and show caution in
  changing things just because we can. we should justify to ourselves
  why, for instance, we're changing KPagedDialog (to pick something
  random out of the air; i don't actually have designed on that one :)
 
 On this front, I think it would be a good idea to try to introduce the
 new api and deprecate the old in a 4.x release where possible, before
 clearing out the deprecated stuff in Platform 5.  This would allow a
 smoother transition, especially for apps that aren't included in SC.

this is what we are planning on doing with libplasma, for instance. only a 
slightly more drastic level. i expect libplasma2 to debut on top of Qt4 and i 
think we will end up shipping, or at least making available, both libplasma1 
and libplasma2, between then and KDE Platform 5.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.


Review Request: remove functions *Command::name() which are not used

2011-05-12 Thread Alexander Potashev

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

Review request for KDE Base Apps and David Faure.


Summary
---

konq-plugins/domtreeviewer builds without there functions.

May be these functions were left for future integration of domtreeviewer 
undoable commands' into Konqueror's undo stack. But for now, they only add a 
few translatable strings the user won't ever see.


Diffs
-

  konq-plugins/domtreeviewer/domtreecommands.h df8272e 
  konq-plugins/domtreeviewer/domtreecommands.cpp e4c7fff 

Diff: http://git.reviewboard.kde.org/r/101343/diff


Testing
---

konq-plugins/domtreeviewer compiles after this change.


Thanks,

Alexander



Re: Accessibility and KDE Sessions

2011-05-12 Thread Aaron J. Seigo
On Tuesday, May 10, 2011 13:00:25 Frederik Gladhorn wrote:
 1) Making Qt load accessibility plugins:
 One possible solution is to query a X-Atom to check if the accessibility
 dbus is running.

just check for the dbus service. no need for X atoms there.

 The downside is that this only works for newly started
 applications. It requires no changes to the existing infra structure and
 can be handled inside Qt with no changes in other places.
 (for comparison, on Windows we get a system call NotifyWinEvent which
 signifies that now the accessibility should be activated... the current

we can do the same with a QDBusServiceWatcher that responds to an a11y dbus 
service name coming or going, ensuring it works even with apps started prior 
to the a11y framework being available.

it could even be made configurable such that unless a11y suport is requested, 
that service watcher object isn't even created. this could live as a QSettings 
entry?

 2) Activating accessibility for a KDE Session
 I have no idea about how to handle this in KDM.
 For KDE in general, we could again persue a similar way to what Gnome does.
 There is the at-spi-dbus-bus.desktop file included in at-spi-2-core which
 takes care of starting a dbus registry and setting up the session as needed
 (starting Orca for example)

we can do something triksy like:

TryExec[$e]=$(kreadconfig ...)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.


Re: KDE/kdeadmin/system-config-printer-kde

2011-05-12 Thread Ozan Çağlayan

23-02-2011 17:09 tarihinde, Jonathan Riddell yazdı:

SVN commit 1222403 by jriddell:

Add samba browsing
https://bugs.launchpad.net/ubuntu/+source/kdeadmin/+bug/295065
BUG:259283


  M  +1 -0  CMakeLists.txt
  A pysmb.py
  M  +363 -40   system-config-printer-kde.py


http://websvn.kde.org/?view=revrevision=1222403


Hi,

I think this commit garbled the s-c-p-kde code a lot. First of all,

You now imported an already available pysmb.py from upstream 
system-config-printer. Why not to use the one
installed on the system as we already depend on debug.py and smburi.py 
from the very same upstream s-c-p in kdeadmin?


The imported pysmb.py brought a python-GTK and thus GTK dependency to 
KDE. I saw that you imported it in try/except and set

PYSMB_AVAILABLE to true/false but you never used it actually.

pysmb.smbc is actually a Python binding for smbc. I think you should 
import smbc directly and depend explicitly on python-smbc project

instead of using it through pysmb wrapper.

Thank you!


Projects in KDE Review for more than two weeks

2011-05-12 Thread Ben Cooksley
Hi all,

The following projects have been in KDE Review for more than 2 weeks.
For those projects which have passed review, please reply indicating
the final module they need to be moved to. Those modules whose review
failed, or whom do not reply need to be moved back to playground.

The projects in review for more than two weeks:
Control Flow Graph
libkface
libkmap
libtagaro
Nepomuk System Tray
libmediawiki

Those people in CC are the people marked as KDE Project Managers for
one or more of the projects. Please respond.

Regards,
Ben Cooksley


Re: Projects in KDE Review for more than two weeks

2011-05-12 Thread Ben Cooksley
On Thu, May 12, 2011 at 8:58 PM, Gilles Caulier
caulier.gil...@gmail.com wrote:
 Hi Ben,

 libkface, libkmap and libmediawiki need to be move into extragear/libs
 component. All are used by digiKam and kipi-plugins for the moment. we
 have already discuted about this move in the past (we cannot find a
 right way to move this libs in an official KDE component as
 kdegraphics.

 So extragear/libs is fine for the moment. next move can be done later
 in another place if necessary.

Ok, they have now been moved to Extragear libraries.


 Q: how do you perform a move from a KDE component as kdereview to
 extragear/libs WITHOUT to lost git commit history ? In the past, a
 simple svn mv been enough. With git it's impossible to do... Do you
 use git export/import feature ? If yes, it sound a complex task to do,
 to simply move code around global git KDE repository. Can you post
 here the command line to use, just to learn this stuff. Thanks in
 advance...

The git repositories themselves on git.kde.org do not move when you
move between playground, review and extragear. If you integrate into a
SC module which uses a monolithic approach, then some special work is
required to integrate the repository history. If it is a split module,
it is a similar change as for playground, review and extragear.

That change is adjusting a setting on KDE Projects (Called Subproject
Of), which at this time is only accessible by Sysadmins (due to a
limitation in Redmine groups unfortunately - it can't handle 2000+
members particularly well)


 Gilles Caulier

Regards,
Ben Cooksley
KDE Sysadmin


 2011/5/12 Ben Cooksley bcooks...@kde.org:
 Hi all,

 The following projects have been in KDE Review for more than 2 weeks.
 For those projects which have passed review, please reply indicating
 the final module they need to be moved to. Those modules whose review
 failed, or whom do not reply need to be moved back to playground.

 The projects in review for more than two weeks:
 Control Flow Graph
 libkface
 libkmap
 libtagaro
 Nepomuk System Tray
 libmediawiki

 Those people in CC are the people marked as KDE Project Managers for
 one or more of the projects. Please respond.

 Regards,
 Ben Cooksley




Re: Projects in KDE Review for more than two weeks

2011-05-12 Thread Gilles Caulier
Hi Ben,

libkface, libkmap and libmediawiki need to be move into extragear/libs
component. All are used by digiKam and kipi-plugins for the moment. we
have already discuted about this move in the past (we cannot find a
right way to move this libs in an official KDE component as
kdegraphics.

So extragear/libs is fine for the moment. next move can be done later
in another place if necessary.

Q: how do you perform a move from a KDE component as kdereview to
extragear/libs WITHOUT to lost git commit history ? In the past, a
simple svn mv been enough. With git it's impossible to do... Do you
use git export/import feature ? If yes, it sound a complex task to do,
to simply move code around global git KDE repository. Can you post
here the command line to use, just to learn this stuff. Thanks in
advance...

Gilles Caulier

2011/5/12 Ben Cooksley bcooks...@kde.org:
 Hi all,

 The following projects have been in KDE Review for more than 2 weeks.
 For those projects which have passed review, please reply indicating
 the final module they need to be moved to. Those modules whose review
 failed, or whom do not reply need to be moved back to playground.

 The projects in review for more than two weeks:
 Control Flow Graph
 libkface
 libkmap
 libtagaro
 Nepomuk System Tray
 libmediawiki

 Those people in CC are the people marked as KDE Project Managers for
 one or more of the projects. Please respond.

 Regards,
 Ben Cooksley



iceScrum (was Re: Qt5 - KDE5?)

2011-05-12 Thread Torgny Nyblom
On Tuesday 10 May 2011 10.04.34 Aaron J. Seigo wrote:
 we have already been putting together plans, including documenting them 
 feature by feature in iceScrum

For those of us who this is the first time we hear about icsscrum where is it, 
who can use it and for what?

/Regards
Torgny


Re: Projects in KDE Review for more than two weeks

2011-05-12 Thread Stefan Majewsky
On Thu, May 12, 2011 at 10:44 AM, Ben Cooksley bcooks...@kde.org wrote:
 libtagaro

Can be moved back to playground/games for now. Has been postponed to
4.8 cycle (discussion on kde-games-devel).

Greetings
Stefan


Re: Projects in KDE Review for more than two weeks

2011-05-12 Thread Ben Cooksley
On Fri, May 13, 2011 at 2:05 AM, Stefan Majewsky
stefan.majew...@googlemail.com wrote:
 On Thu, May 12, 2011 at 10:44 AM, Ben Cooksley bcooks...@kde.org wrote:
 libtagaro

 Can be moved back to playground/games for now. Has been postponed to
 4.8 cycle (discussion on kde-games-devel).

Moved back to playground/games as requested.
Thanks for responding.


 Greetings
 Stefan


Regards,
Ben


Re: iceScrum (was Re: Qt5 - KDE5?)

2011-05-12 Thread Shaun Reich
On Thu, May 12, 2011 at 8:38 AM, Torgny Nyblom nyb...@kde.org wrote:
 On Tuesday 10 May 2011 10.04.34 Aaron J. Seigo wrote:
 we have already been putting together plans, including documenting them
 feature by feature in iceScrum

 For those of us who this is the first time we hear about icsscrum where is it,
 who can use it and for what?

http://contour-scrum.basyskom.org/icescrum/

-- 
Shaun Reich,
KDE Software Developer (kde.org)


Re: iceScrum (was Re: Qt5 - KDE5?)

2011-05-12 Thread Aaron J. Seigo
On Thursday, May 12, 2011 14:38:57 Torgny Nyblom wrote:
 On Tuesday 10 May 2011 10.04.34 Aaron J. Seigo wrote:
  we have already been putting together plans, including documenting them
  feature by feature in iceScrum
 
 For those of us who this is the first time we hear about icsscrum where is
 it, who can use it and for what?

Shaun gave the location; it's still experimental for us, though. We're using 
it for the next three months of plasma development, with a focus on Plasma 
Active issues, as a trial.

If this works out well, we will find a more permanent home somewhere under the 
KDE infrastructure umbrella and open the invitation to use it to more people.

If there is interest sooner, then perhaps someone can look into speeding up 
that timeline.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.


Re: USian vs. American (was: US Week Numbers)

2011-05-12 Thread Keith Rusler
Well I don't think anyone in Canada would call themselves American even if
it's referred to the continent nor would Québéc's. How would you even
pronounce USian it isn't even a really word. If you want to refer someone as
American other than the US, you normally refer to them as North American
or South American The reason why we Americans use it is simply because
America is in our countries name. If it wasn't we could Statians but
probably not since it's close to Satanists which would offer people, we
couldn't use United as that's part of a few countries maybe more. I wonder
if people call UK people UKians, I always refer to them as the British
rather than Britians or UKians. LOL. The way I simply look at it is like
this. Gay people like to be referred to as Gay's but to call them anything
other than that it's offensive. I don't speak for everyone else. But to call
me other than anything but American (it's what I've been known as more than
anything since I was born) and it's been that way since the start of
civilisation in this country. To call US anything but that shows us
disrespect imho. I'm not here to start wars on this or anything.

On 12 May 2011 03:02, Hans Meine hans_me...@gmx.net wrote:

 Am Donnerstag, 5. Mai 2011, um 00:54:10 schrieb Keith Rusler:
  That's fine, I'm just clarifying it that yeah it might sounds dumb that
 US
  citizens are called Americans, but we was just always were called it in
  anything that you see on TV, etc. ;P

 People from Canada (Montreal in particular) seem to have a different
 opinion on
 the term American or America AFAICS.

 Anyhow, it looks as if mistakes should be tolerated in any case. :-)

 Best,
   Hans



Re: iceScrum (was Re: Qt5 - KDE5?)

2011-05-12 Thread Torgny Nyblom
 On Thursday, May 12, 2011 14:38:57 Torgny Nyblom wrote:
 On Tuesday 10 May 2011 10.04.34 Aaron J. Seigo wrote:
[...]
 Shaun gave the location; it's still experimental for us, though. We're
 using
 it for the next three months of plasma development, with a focus on Plasma
 Active issues, as a trial.

 If this works out well, we will find a more permanent home somewhere under
 the
 KDE infrastructure umbrella and open the invitation to use it to more
 people.

 If there is interest sooner, then perhaps someone can look into speeding
 up
 that timeline.

Thanks (Aaron and Shaun) for that, I think that it look interesting and am
looking forward to hear what your impressions are after this first
sprint.

If you think that it is good I would love to have an official KDE version
running for us all to use.

/Regards
Torgny