headers
Chusslove Illich | 1 Jul 2007 10:48
Picon

Re: Some changes in KCmdLineArgs, KAboutData and KComponentData

> [: Chusslove Illich :]
> Therefore, I want to switch them as follows: [...]

I intend to commit these changes tomorrow, if there are no objections.

In the meantime I have auto-converted and hand-corrected by compilation
trunk/KDE and trunk/koffice, and auto-converted trunk/extragear and
trunk/playground (what was KDE4 code in them).

--

-- 
Chusslove Illich (Часлав Илић)
Permalink | Reply | 0 comments |
headers
Joseph Wenninger | 1 Jul 2007 15:35
Picon
Favicon

Re: kio_http bug

Hi !

I noticed the same problem. If it is not fixed yet, it really should be fixed. 
Don't know if it is a bug of the http kio slave or the kxmlrpcclient in 
kdepimlbs.

Kind regards
Joseph Wenninger

On Saturday 23 June 2007 03:18, Antonio Aloisio wrote:
> Hello! I'm working on kblogger and i've some problem with
> kdepimlibs/kxmlrpcall. Kxmlrpcall, use kio_http to post the XML request.
> I've observed that the first xml request that create the kio_http slave
> works fine,
> but the second one (that use the previous created kio_http slave) send a
> empty XML request.
>
> The bug is in
>     kdelibs/kioslave/http/http.cpp
> in
>     bool HTTPProtocol::sendBody()
> line:
>     if ( !m_bufPOST.isNull() )
>
> So, i've commented the line
>
>   // m_bufPOST will NOT be empty iff authentication was required before
> posting // the data OR a re-connect is requested from ::readHeader because
> the // connection was lost for some reason.
>   /*if ( !m_bufPOST.isNull() )
(Continue reading)

Permalink | Reply | 4 comments |
headers
Pau Garcia i Quiles | 1 Jul 2007 16:44
Favicon

Re: konqueror 'progress' indicator into kdelibs?

Quoting Thomas Zander <zander <at> kde.org>:

> Hiya,
>
> In konqueror (and all other webbrowsers) there is an indicator for
> internet activity. We typically have a animating gears in plain KDE.
>
> One thing we learned from web-apps is that users like web-services. And in
> KDE we tend to integrate those more and more.  Think about marbles
> wikipedia integration as a quick example.
>
> In KOffice I want to have several kinds of services integrated as well,
> and I was thinking about how to do the interaction model.  The biggest
> problem I see is that the internet may be slow and thus that 'browsing'
> may take longer then a user would expect from a desktop application.
> As a specific usecase I was thinking about having a way to browse
> openClipart.org using their webservice and showing the results directly
> in a custom widget instead of something html based.
>
> Based on this issue I want to propose we use the common "internet activity
> busy" indicator in various places in KDE. People know this already and I
> am sure will appreciate the familiar indicator. This would require the
> animating logo as it is in konqueror to be moved up to kdelibs.
>
> What do you guys think?
> Anyone that knows where this stuff is can do it? Or tell me enough to do
> it?

Would KUiServer work for what you want to achieve?
http://websvn.kde.org/trunk/KDE/kdebase/runtime/kuiserver/
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thiago Macieira | 1 Jul 2007 16:54
Picon
Favicon

Re: Qt4 gui performance

Tobias Koenig wrote:
>I just feared that I'll have to explain on linux events why the new KDE
>is so slow although we promised with Qt4 everything would be faster :)

I am not saying all your problems are solved :-P

But I am saying that the comparison you did wasn't fair.

--

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Permalink | Reply | 0 comments |
headers
Thiago Macieira | 1 Jul 2007 17:03
Picon
Favicon

Re: DESTDIR/etc

Allen Winter wrote:
>Howdy,
>
>Just curious why we have only $DESTDIR/etc when it seems
>so sparesly populated.
>
>What's the purpose of the this top-level dir?
>
>All I see in there after installing several of the modules is
>$DESTDIR/etc/xdg/menus/applications.menu

The purpose of that dir is to fill in the XDG menus, really. They are 
supposed to be installed into $sysconfdir.

--

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Permalink | Reply | 0 comments |
headers
Simon Hausmann | 1 Jul 2007 17:52
Picon
Favicon
Gravatar

Re: Qt4 gui performance

On Saturday 30 June 2007 18:48:38 Andreas Hartmetz wrote:
> On Friday 29 June 2007 17:56:29 Tobias Koenig wrote:
> > Hi,
> >
> > I just wanted to ask whether somebody else have the same feeling that
> > Qt4 applications are recognizable slower in painting windows and widgets
> > than Qt3 applications.
>
> You can enable optimization in debug builds by editing the file
> qt-copy/mkspecs/common/g++.conf:
> change
> QMAKE_CFLAGS_DEBUG     += -g
> to
> QMAKE_CFLAGS_DEBUG     += -g -O2
>
> You'll probably lose line-by-line debugability due to optimization, but
> that should be OK if you are not interested in major Qt bugfixing.

Instead of modifying mkspecs/common/g++.conf you can also just configure Qt 
as-is. If you _don't_ pass -debug or -release to Qt's configure then the 
toolkit is built with -O2 and -g by default.

Simon
Permalink | Reply | 0 comments |
headers
Rafael Fernández López | 1 Jul 2007 17:55
Picon
Gravatar

Re: konqueror 'progress' indicator into kdelibs?

Hi all,

Finally we have Internet on aKademy !! Hooah !!

Nope, KUIServer's purpose is not that. KUIServer is meant to notify progress 
to users, not internet/net activity.

Bye !!
Rafael Fernández López.
Permalink | Reply | 0 comments |
headers
Matthew Woehlke | 3 Jul 2007 03:30
Picon
Gravatar

Re: A11y guidelines for styles in core KDE - style devs, please read!

Fredrik Höglund wrote:
> On Wednesday 27 June 2007 21:24, Matthew Woehlke wrote:
>> The usability group has recommended that widgets that currently have 
>> input focus be drawn in a different manner using a designated color 
>> which is (currently) part of KColorScheme. And we're also attempting to 
>> standardize the color used to indicate widgets that can currently be 
>> clicked (i.e. the "hover" color).
>>
>> There are two problems: one, apparently none of the style developers has 
>> heard about this until now, and two this currently requires styles to 
>> link to kdeui (which reportedly causes crashes). So this is an attempt 
>> to get the right people reading and involved in the conversation.
>>
>> We need to figure out some resolution, and if it involves API changes, 
>> we need to figure one out *fast* (else at best we already have dead 
>> API's in kdeui).
> 
> It seems to me that this is a perfect example of why you should have
> done this in a branch until you've proved that the API works and is
> usable, and only then merged it into trunk.

And for the optimists in the audience... thanks to some timely help from 
David Faure and Matthias Kretz, I think I have the second issue 
resolved. Not as cleanly as I would like (basically, styles can't use 
KGlobal, and therefore a workaround is needed; more tomorrow when I can 
get the patch assembled for presentation), but I'm not seeing any 
problems, so it looks like styles can safely (read: carefully!) use 
kdeui after all.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Matthew Woehlke | 3 Jul 2007 03:33
Picon
Gravatar

Re: make kdeui loadable by styles, kill/merge kdefx

David Faure wrote:
> On Saturday 30 June 2007, Matthew Woehlke wrote:
>> David Faure wrote:
>>> On Friday 29 June 2007, Matthew Woehlke wrote:
>>>> I know I've heard people talk about wanting to kill/merge kdefx, and I 
>>>> recently learned that the reason it exists as a separate library is (at 
>>>> least in part) due to some issues loading kdeui outside of a KApplication.
>>> ... and problems when unloading libraries.
>>> (not depending on kapp is something we have already fixed in kdelibs4).
>> Really? ;-)
> Yep.
> 
>> $ designer -style Plastik
>> Fatal error: you need to have a KComponentData object before
>> you do anything that requires it! Examples of this are config
>> objects, standard directories or translations.
>> Aborted
>>
>> What's going on here I think is the code tried to do KGlobal::config(), 
>> KConfigGroup() and readEntry(), and it choked at one of those steps. I 
>> don't think it's doing anything else as far as using objects in kdeui.
> [snip]
> Well, none of that has anything to do with KApplication itself.
> The application class isn't the problem.
> However if you get this error, it means you (well, not you, but
> the plastik style) should instanciate a KComponentData instance.

Ah, yes. Well, that's not as easy as it sounds, but after some 
KComponentData ctor hacking, thanks to Matthias Kretz, it seems to be 
working. So it looks like you're right that kdeui is usable... as long
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Richard Tyrer | 2 Jul 2007 02:51
Picon
Favicon

Re: konqueror 'progress' indicator into kdelibs?

Maksim Orlovich wrote:
> <snip>
> 
>> busy" indicator in various places in KDE. People know this already and I
>> am sure will appreciate the familiar indicator. This would require the
>> animating logo as it is in konqueror to be moved up to kdelibs.
>>
>> What do you guys think?
>> Anyone that knows where this stuff is can do it? Or tell me enough to do
>> it?
> 
> It was in kdelibs in 3.x --- KAnimWidget; but seems like it got moved in
> 4.x..

Actually, it was renamed to: "KAnimatedButton" which is in:

	kdelibs/kdeui/widgets/kanimatedbutton.cpp

The other question is the PNG which this will use.  According to the 
Icon Naming spec, there are to be two PGNs:

	animations/process-idle.png
	animations/process-working.png

with the "process-idle" being new, and "process-working" to be the 
multiple image like the current: "kde".  With old icon themes, we have 
little choice but to rename: "kde" to "process-working" and place the 
first frame in the new icon: "process-idle".  However, the use of cross 
platform icon names and themes raised an important question.  Do we want 
new artwork for these new icons (e.g. Oxygen) to be KDE branded since it
(Continue reading)

Permalink | Reply | 0 comments |

Gmane