PATCH: kdelibs/kio/kio/kprotocolinfo.*

Patch below un-deprecates three functions in kprotocolinfo that were marked 
deprecated when the "source protocol" idea was implemented. These functions 
only read the config file for a given protocol and hence have no involvement 
with determining whether or not a given protocol has its own source protocol 
(this mainly applies to proxying FTP over HTTP). Any objections if I 
undeprecate them ? They are used in the URIFilter plugins as they are more 
convenient.

--

-- 
Regards,
Dawit A.
"Preach what you practice, practice what you preach"

KDE wide functional test infrastructure

Hey folks,

in a recent thread on the kmail list we've been discussing that it would be 
very nice to have a set of functional tests (as opposed to unit tests) which 
can be performed by folks willing to help before releases, or even regularly 
by people running cvs, in order to quickly identify regressions etc. I'm 
confident the concept is not alien to any of you and I don't need to 
elaborate on the merits of such an infrastructure. 

The test descriptions could (should) be published somewhere on the pim website 
(possibly autogenerated from cvs) for people to execute them. The format 
could be use case diagrams (Yeah! for umbrello ;) or plain text descriptions 
or whatever.

While trying to decide on where to put this stuff it dawned on us that it 
might be a good idea to set up a kde wide module for stuff like that. kde-qa, 
kdetests, whatever, with a pim subdir in it, which could also be the home of 
khtmltests, for example. The alternatives are:

- a subdir in kdepim called regression_tests, or whatever, which would rather
  tighly couple the infrastructure to the pim cvs module but keep stuff local
- a standalone module kdepimtests which testers could check out standalone

Should a kde wide qa/regression tests/functional tests infrastructure be 
deemed desireable by all of you, if would probably be a good idea to agree on 
formats early on and maybe decide on a place on kde.org for it.

Of course this only makes sense if the infrastructure is maintained and the 
tests are executed, so some kind of test team would need to be recruited. If 
we manage to communicate the difference in quality those folks could make, 

Re: KDE wide functional test infrastructure

An idea: can you use Python+DCOP for this level of testing? Not only would it 
lend itself to automation, it would help ensure a complete level of DCOP API.

[ The Python bit is just my personal preference for a portable, db-capable, 
scripting environment ]

kdelibs/pics/crystalsvg

CVS commit by antlarr: 

I'm sorry I didn't had free time until today to fix the problem with the fuzzy
icons in the system tray, but here it is.
The problem was that the 22x22/apps directory wasn't declared in the icon
theme so the icon loader didn't look into it and so, it could only return
the icon with the nearest size.

This file was quite wrong. It included duplicated entries for some
directories so we were looking twice into them slowing the applications
innecesarily!
And even more, had duplicated entire config groups, so it could produce
problems if we changed one of them in the future and kconfig would keep
reading the other one.

CCMAIL: kde-core-devel <at> kde.org, everaldo <at> everaldo.com

  M +38 -79    index.theme   1.9

Re: build failure in kdebase

Craig Drummond wrote:
> On Friday 31 October 2003 17:48, Benjamin Reed wrote:
> 
>>Craig Drummond wrote:
>>
>>>Can you re-update both kcontrol/fonts and kcontrol/kfontinst -
>>>kxftconfig.cpp is nolonger #included into XConfig.cpp
>>
>>I already did, that's the error I get with the new code (I just upped
>>again to make sure, and it's unchanged -- I've got a real CVS account
>>too, so it's not an anoncvs issue).
> 
> 
> There seems to be something wrong with your build system. As explained there 
> are 2 different prototypes for this function - a fontconfig and an xftconfig 
> version. These are controlled by the HAVE_FONTCONFIG #def - which is listed 
> in kdebase/config.h, and this is generated by ./configure (which checks for 
> the fontconfig library).

Now I see the issue.

Mac OS X uses a case-insensitive filesystem.  In the local directory, 
there is a "Config.h" that gets matched first, so it never includes the 
"real" config.h.  This will likely break cygwin as well, since they have 
the same issue.  Not sure if there are any other unixes out there with 
case-insensitive FSes that might be affected too.

As I see that it's in noinst_HEADERS, do you have any objection to 
renaming it?

Re: build failure in kdebase

> Mac OS X uses a case-insensitive filesystem.  In the local directory,

Case-insensitive - how pathetic! Whay have a UNIX fs that isn't case 
sensitive?

> there is a "Config.h" that gets matched first, so it never includes the
> "real" config.h.  This will likely break cygwin as well, since they have
> the same issue.  Not sure if there are any other unixes out there with
> case-insensitive FSes that might be affected too.
>
> As I see that it's in noinst_HEADERS, do you have any objection to
> renaming it?

OK - I'll get round to renaming it, as this seems the easiest way. Stupid Mac 
OSX fs...

Craig.

Re: build failure in kdebase

Craig Drummond wrote:

>>Mac OS X uses a case-insensitive filesystem.  In the local directory,
> 
> Case-insensitive - how pathetic! Whay have a UNIX fs that isn't case 
> sensitive?

Well, Mac OS X supports UFS, but the OSX implementation is pretty buggy 
and is not the default FS used.  As of the new release, they support a 
case-sensitive version of HFS+ (the mac os filesystem) but not on the 
root volume for some reason, my guess was either they didn't have enough 
time for Q/A to make it "official", or they're only making it an install 
option for OSX Server.

> OK - I'll get round to renaming it, as this seems the easiest way. Stupid Mac 
> OSX fs...

It was hard for me to get used to as well, but I can at least understand 
the usability argument for a case-insensitive one.  Case-sensitive 
filesystems make sense to programmers, but not to users.

Regarless, there are systems that have such things, and it's a simple 
fix, so I appreciate the help.  :)

--

-- 
Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/
gpg: 6401 D02A A35F 55E9 D7DD  71C5 52EF A366 D3F6 65FE
<jbeimler> yeah, rpm is for people who can't keep track of hundreds
            of scraps of paper

Re: build failure in kdebase

> Regarless, there are systems that have such things, and it's a simple
> fix, so I appreciate the help.  :)

Anyway - I've just made the changes, please update and try.

Craig.

Re: build failure in kdebase

Latest changes work fine.  Thanks again, Craig.  Time to finish 
packaging beta1.  :)

--

-- 
Benjamin Reed a.k.a. Ranger Rick -- http://ranger.befunk.com/
gpg: 6401 D02A A35F 55E9 D7DD  71C5 52EF A366 D3F6 65FE
"You can scoff, Lister, that's nothing new.  They laughed at Galileo.
They laughed at Edison.  They laughed at Columbo."   "Who's Columbo?"
"The man with the dirty mac who discovered America."   -- _Red Dwarf_

[PATCH] #59954

Hi,

can I commit the attached patch to fix
  http://bugs.kde.org/show_bug.cgi?id=59954
The solution of the author sounds logical, but I'm not sure if there is
not another way.

Ciao,
Tobias
-- 
Can a government that shoots at reporters be democratic?
Separate politics from religion and economy!

Index: common_texts.cpp
===================================================================
RCS file: /home/kde/kdelibs/common_texts.cpp,v
retrieving revision 1.21
diff -p -u -b -r1.21 common_texts.cpp
--- common_texts.cpp	28 Nov 2002 22:31:04 -0000	1.21
+++ common_texts.cpp	1 Nov 2003 19:28:15 -0000
 <at>  <at>  -178,6 +178,7  <at>  <at>  i18n( "Open Recent");
 i18n( "Open &Recent");
 i18n( "&Find...");
 i18n( "Find &Next");
+i18n( "Bookmarks");
 i18n( "&Bookmarks");
 i18n( "&Add Bookmark");
 i18n( "&Edit Bookmarks...");