headers
Parker Coates | 6 Oct 08:45

[PATCH] KDialog::groupSpacingHint()

Hello,

The latest KDE HIG offers using a vertical space of 16 pixels as an
additional method of grouping logically related items in a dialog. [1]
Rather than have this 16 pixel value hardcoded in dozens of different
dialogs, I propose adding a groupSpacingHint() method to the KDialog
class. [2] This is a static method that returns a constant in the same
vein as KDialog::marginHint() and KDialog::spacingHint().

The attached patch adds such a method. Any comments?

Parker

[1] http://techbase.kde.org/Projects/Usability/HIG/Form_Label_Alignment#Grouping_related_options_within_a_GroupBox

[2] I realise that KDialog isn't necessarily the most logical place
for these functions to live, but spacingHint() and marginHint() are
already there and placing groupSpacingHint() anywhere else would be
even less logical.
Attachment (kdialog.diff): text/x-diff, 2771 bytes
Permalink | Reply | 2 comments |
headers
Josef Spillner | 5 Oct 18:49

Making kio_http more accessible to RESTful clients

Hello,

to make the creation of clients to RESTful services possible, applications 
need access to HTTP response codes.
Since I'm not too familiar with the KIO code, I'm asking here first before 
putting in my patches from playground/libs/webtech.

- slavebase: Why is metadata discarded in the case of error()? It seems more 
useful to me to keep it.
- deletejob: It surely is an error that it creates a subjob and then dismisses 
the subjob's metadata?
- kio_http: Its desktop file only indicates reading capabilities, whereas 
writing and deleting is also supported. What's the reason behind this 
restriction?
- kio: What is the rationale for having specialised methods like 
KIO::http_post when all the functionality they include could be expressed by 
the existing methods? Such methods should be removed or put into convenience 
classes.

For KDE 5, my wishlist includes splitting the WebDAV code from the HTTP code, 
to make the class more maintainable and more useful for other HTTP-based 
protocols. Also, the API naming convention regarding metadata is very lousy, 
it is hard to differentiate between outgoing and incoming data, especially in 
KIO::Job::{setM,m}etaData().

Josef
Permalink | Reply | 5 comments |
headers
Albert Astals Cid | 5 Oct 16:58

Remove "" from KStandardDirs

Looking at the code seems correct. Testsuite is ok. Ok to commit?

Albert
Attachment (kstandarddirs.cpp.patch): text/x-diff, 738 bytes
Permalink | Reply | 3 comments |
headers
Allen Winter | 5 Oct 14:50

4.2 Feature Plan

Howdy all,

Please don't forget to add items (or update the status of existing items) to the 4.2 Feature Plan.

http://techbase.kde.org/Schedules/KDE4/4.2_Feature_Plan

The 4.2 Soft Feature Freeze is coming in 2 weeks.

To learn more about the Soft Feature Freeze, please read:
http://techbase.kde.org/Schedules/KDE4/4.2_Release_Schedule#October_19th.2C_2008:_Soft_Feature_Freeze

Regards,
Allen, KDE Release Team
Permalink | Reply | 0 comments |
headers
Christoph Bartoschek | 4 Oct 13:35

[PATCH] Removing unnecessary friend declarations from kcolordialog.h

Hi,

the following patch removes three unnecessary friend declarations from 
kcolordialog.h.

This patch is necessary to compile KDE code with EDG-based compilers. They 
choke on the second and third firend declaration, because they seem to be 
obviously wrong.

Christoph
Attachment (kcolordialog_friends.patch): text/x-diff, 705 bytes
Permalink | Reply | 6 comments |
headers
Christoph Bartoschek | 4 Oct 12:40

Suspicious code in revision 867140 (Part 2)

- kdebase/workspace/klipper/urlgrabber.cpp:405

Line 395 indicates that myMenu can be NULL here.

- kdebase/workspace/solid/networkmanager-0.7/manager.cpp:254

A default case for the switch in line 239 would catch possible errors if
additional states are added.

- kdebase/workspace/solid/networkmanager-0.7/wirelessnetworkinterface.cpp:205

A default case for the switch in line 186 would catch possible errors if
additional modes are added.

- 
kdebase/workspace/plasma/dataengines/nowplaying/playerinterface/mpris/mpris.cpp:344

The expression is always false. !caps can be 0 or 1. CAN_PROVIDE_METADATA
is (1 << 5)

- kdebase/workspace/plasma/shells/desktop/panelview.cpp:82

Line 74 indicates that panel can be NULL here.

- kdebase/workspace/plasma/tools/engineexplorer/main.cpp:59, 66

No need to use boolean arithmetic here.

- kdebase/workspace/plasma/tools/engineexplorer/serviceviewer.cpp:101
(Continue reading)

Permalink | Reply | 17 comments |
headers
David Faure | 4 Oct 00:13

Convenience kdesupport tags for building kdelibs-4.1.x

The release-team has decided to improve the organization of the kdesupport system we use.
Please read the details below.

Problem
------------
KDE development is divided in several branches, especially the current stable KDE branch and the unstable
development branch in trunk. kdesupport libraries are independent of KDE, but KDE depends on them. At
this moment there is no indication at all which kdesupport library should be used for a certain KDE branch.

We want a simple system for developers to just know for sure that they got the right kdesupport libraries
when they want to compile a KDE tree completely from subversion.

In addition, kdesupport developers have indicated that they would like to be able to work in trunk without
the constant fear of breaking compilation in some remote module and being yelled at by 500 people :)

Solution
------------
For each main kde tree we will create a tag. For example for the current stable KDE release I just created a tags/kdesupport-for-4.1/kdesupport.
Within that folder there are (cheap) copies of the kdesupport libraries which should be used for compiling
the KDE 4.1 tree. For example:
   tags/kdesupport-for-4.1/kdesupport/phonon/    (svn cp'ed from tags/phonon/4.2.0)
   tags/kdesupport-for-4.1/kdesupport/strigi/    (svn cp'ed from tags/strigi/strigi/0.5.11)
   tags/kdesupport-for-4.1/kdesupport/qca/    (svn cp'ed from tags/qca/2.0.1)
It contains a CMakeLists.txt file, so all subdirectories can be built in one go. So if you want KDE-4.1, just
simply checkout this tag before compiling kdelibs and you are done. For those using kdesvn-build, it
means simply adding this line in the kdesupport module:
  module-base-path tags/kdesupport-for-4.1

The same will go for trunk, so we will create a kdesupport-for-trunk. This also contains copies to the right
version of the kdesupport libraries needed to build trunk. That means developers have a choice: either
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christoph Bartoschek | 3 Oct 16:24

Suspicious code in revision 867140

Hi,

here are the reports for revision 864329 that had no feedback:

- kdelibs/kate/completion/katecompletionconfig.cpp:226
  kdelibs/kate/completion/katecompletionconfig.cpp:176

If the condition in line 225 is true for the first iteration then the shift
amount is i - 1 == -1 in line 226. This is invalid.

- kdepimlibs/kioslave/imap4/imap4.cpp:150

A signal handler that calls for example waitpid has to save errno before and
restore it afterwards.

- kdebase/workspace/ksysguard/gui/SensorDisplayLib/SignalPlotter.cc:635

Line 604 indicates that mVerticalLinesDistance can be 0. If this is the case
and the execution reaches this line, then a devision by 0 is the result.

- kdebase/workspace/ksysguard/gui/WorkSheet.cc:548, 551

If the condition in line 538 is false then newDisplay is NULL here.

- kdebase/workspace/powerdevil/kcmodule/CapabilitiesPage.cpp:205

There is no need to confuse the reader and use the bitwise-or here.

- kdebase/workspace/powerdevil/kcmodule/CapabilitiesPage.cpp:304
(Continue reading)

Permalink | Reply | 6 comments |
headers
Fred Emmott | 1 Oct 12:20

./configure -no-exceptions recommended in qt-copy

Hi,

How much of an effect does this have on modern compilers?

I'd like to suggest removing it from the recommended configure line in 
README.qt-copy because:

- I don't believe the overhead will be significant

- It blocks the build of QtXmlPatterns (-no-exceptions -xmlpatterns makes 
configure complain, and -no-exceptions just doesn't build xmlpatterns). There's 
two problems with this:

- In my opinion, this should stop KDE applications from using QtXmlPatterns - 
they should be buildable with a Qt built following the recommendations in 
README.qt-copy; I don't think any do at the moment, but it is a very useful 
module.

- If distributions (such as slackware and slamd64's current/testing does now) 
ships qt4 built following those recommendations, it stops non-KDE apps that 
use QtXmlPatterns being built with distribution Qt packages.

Regards,

--

-- 
Fred Emmott
(http://www.fredemmott.co.uk)
Permalink | Reply | 3 comments |
headers
Michael Leupold | 3 Oct 00:11

freedesktop.org single sign-on project

Hi,

I finally got around gathering some information for planning said fd.o project 
and wanted to share some insights and also gather some information and 
opinions.

The goal of the project is to allow a user to authenticate once to a central 
authority (eg. a daemon) without having to reenter authentication information 
again during the session (if he wishes so).

Part of such a daemon is currently provided by kwalletd which stores passwords 
in a symmetrically encrypted file on disk that's decrypted using a password 
entered by the user. Any application can then use the wallet to retrieve and 
store authentication information. Thus a part of the specification will be 
about how communication between the daemon and client applications works. This 
will enable any application (regardless if GNOME, KDE, Mozilla or whatever) to 
use a secure storage for passwords with having the user authenticate ONCE to 
the daemon (and not 3 times to 3 daemons).

However there's more to it. Authentication can also be done using client 
certificates, popular examples being SSH or SSL. As those secret keys are 
stored encrypted on disk as well, the user has to unlock each of them if he 
wants to use it (eg. by using ssh-add or entering the password in a 
webbrowser). Ideally a single sign-on daemon would provide means to "unlock" 
client keys automatically.

I think it would also be possible to support external SSO mechanisms like 
Kerberos or various shared sign-on techniques. However as I don't know about 
those (yet) I don't know what "supporting" them would consist of.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Stephen Kelly | 2 Oct 04:37

Reorganising techbase around "Contributor Paths".

Hi,

As far as I know, the focus of techbase is for documentation, information,
policies, schedules etc around producing KDE products, and bringing new
contributors into that. Aspects include coding, translation, documentation,
art, bugfixing etc.

However, currently techbase is mostly structured around development. Other
aspects have been added in places but the main navigation structure of it
does not really reflect that.

http://techbase.kde.org/Welcome_to_KDE_TechBase

On the homepage we have 

* Setting up a KDE development environment (/Getting_Started)
* Developing with KDE (/Development)
* KDE System Administration (/KDE_System_Adminitration) (Should be on
userbase I think)
* Join the KDE Team and Contribute (/Contribute) (This is all about dev, but
with a link to kde.org/getinvolved.)
* ISV Information (/ISV) (Some of this is way out of date. Should it be on a
wiki at all, or is www.kde.org better for this stuff)
* KDE projects (/Projects)

Techbase might have started out being all about development, and we now have
a lot of good development tutorials. We also have a lot of other great
tutorials on internationalization and documentation etc, but the
organization of techbase doesn't make them easy to find.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane