headers
Scott Wheeler | 1 Jan 2004 01:56
Picon
Favicon

Re: Regarding kpdf

On Tuesday 30 December 2003 22:05, George Staikos wrote:

>   I agree that it needs to be removed.  I have already asked for it (along 
> with other dead code) to be moved to kdenonbeta but I did not receive a 
> reply.

For what it's worth I've had a lot of problems with it too.  It's difficult to 
get it to build on an older distro -- much less work.  There are a lot of 
code paths that aren't hit because of ifdef's that don't seem to have been 
tested much that cause problems if you're missing some of the soft 
dependencies.  I'd also prefer to see it moved back to kdenonbeta for 3.2 and 
if it's in better shape in a few months discuss bringing it back for 3.3...

-Scott
Permalink | Reply | 30 comments |
headers
Shaheed | 1 Jan 2004 13:47

Reducing the support effort for Indic support in Qt/KDE 3.2


Hi all,

As more and more people start to use the new Indic support, I am beginning to
understand that they will come across pages like

http://www.prothom-alo.net/newhtmlnews1/category.php?CategoryID=1&Date=2004-0
1-01

which render with a lot of errors. Some of these errors will result in the 
drawing of unfilled squares because of "missing" font glyphs. (If you look at 
the source in this case, it seems that the content was generated using MS 
software and the "Arial Unicode MS" font - that will be true of many pages)

In these cases, it might be useful to do as Mozilla does and draw the square
with number of the QChar in it. I think that would make it easier for people
to debug font/encoding issues.

Thoughts? Shaheed
Permalink | Reply | 1 comment |
headers
Martijn Klingens | 1 Jan 2004 15:25
Picon
Favicon

QMovie leaking lots of pixmap resources

In Kopete we have a bug where just opening a chat window and leaving it open 
starts leaking memory and eventually makes Kopete or the entire box crash 
(http://bugs.kde.org/show_bug.cgi?id=62669).

I tracked this down to a QMovie that starts leaking the pixmaps even when it 
is NOT being used! Just the loadMovie call in 
kdenetwork/kopete/kopete/chatwindow/kopetechatwindow.cpp around line 462 is 
enough to trigger it. To view for yourself: start Kopete, fire up xrestop or 
your own favourite debugging tool and watch Kopete leak about 30 kb/sec as 
soon as you open a chat window.

The problem is, I have *no* idea why it starts leaking. Commenting out the 
loadMovie call stops it. Replacing loadMovie() with a manual 
QMovie( "/full/path/to/movie.mng" ) does not solve the problem, nor does 
creating a standalone movie using 'new QMovie( "/some/path" )'.

However, when I try to create a small test app containing

int main( int argc, char *argv[] )
{
	QApplication app( argc, argv );

	QWidget w( 0L );
	w.show();
	app.setMainWidget( &w );

	// This works as expected
	QMovie m( "test.mng" );

	app.exec();
(Continue reading)

Permalink | Reply | 10 comments |
headers
Simon Hausmann | 1 Jan 2004 16:13
Picon
Favicon
Gravatar

Re: KDE + Qt/Mac -- how to handle it?

On Wednesday 31 December 2003 21:04, Benjamin Reed wrote:
> (KDE-Darwin folks, please reply only to the KDE-Darwin list,
> kde-core-devel is moderated...)
>
> As some of you may have noticed, we're starting to hit a point where
> things are working in porting KDE to Qt/Mac.  My question to you is how
> to go about handling the port, and getting it back into the mainline
> sources.
>
> Initially, it was mostly me working, off of Sam Magnuson's original
> port, but now that we've got a few people contributing it's getting
> unwieldy to keep patchsets around.
>
> I'm loathe to just start committing to head because the patches are a
> lot of ugly #ifdef's and unimplemented bits, but at the same time, since
> they're #ifdef'd the only people they really affect are people using
> Qt/Mac.
>
> My thought is there's 2 different ways to go about it:
>
> 1. Just commit to head; it introduces a little bit of entropy but while
> ugly, the patches are pretty safe.
> 2. Make a branch for Qt/Mac development.
>
> I'd rather do 1 just because it's easier, the only reason I'm a bit
> reticent to do so is because we're still in freeze for KDE 3.2.  It's
> not like we're doing anything that isn't already in the tree (Holger
> Schroeder's initial work on chopping out some of the X11-specific stuff
> is already in CVS, and has been for months).
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dirk Mueller | 1 Jan 2004 16:57
Picon
Favicon

Re: QMovie leaking lots of pixmap resources

On Thursday 01 January 2004 15:25, Martijn Klingens wrote:

> Does anyone here have any idea where the leak comes from? I can 100%
> reproduce it in Kopete and not at all outside Kopete. 

valgrind is useful in finding memory leaks. You can download it from 
http://valgrind.kde.org/ and run it on your application with 
--leak-check=yes. 

Dirk
Permalink | Reply | 2 comments |
headers
Benjamin Reed | 1 Jan 2004 16:59
Gravatar

Re: KDE + Qt/Mac -- how to handle it?

Simon Hausmann wrote:
> I looked through some of the patches (not all of it). Here are some comments:
> 
> koffice: I think instead of hardcoding 75 Dpi for non-x11 it'd be better to 
> use the QPaintDeviceMetrics API.

Yeah, the hardcoding is just a first step to get it running.

I started looking into the QPaintDeviceMetrics stuff but haven't grok'd 
it enough to implement anything.  I'm really not much of a coder, 
although I can #ifdef the hell out of something....  =)

> kdebase:
> 
> There are a lot of patches to kicker, and 'later' on kicker is disabled from 		
> compilation (which makes sense for Mac, I guess) . I think just conditionally 
> (not unconditinally, like right now in the patch!) disabling kicker is better 
> than to also add all the #ifdefs.

Yeah, I got halfway through and realized there's really no point in 
finishing getting kicker to compile, so I just disabled it.  =)

> There are also a few places where you changed char **argv to char *argv[] . 
> Why is that?

Good question, I don't remember why I did that.  =)

> In konq_main.cc: You disable konq preloading based on the non-X11 define. Why 
> not disable it specifically for mac only, not generally using non-X11 
> defines?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dirk Mueller | 1 Jan 2004 17:07
Picon
Favicon

[PATCH] fix kwin passive grab leaks

Hi, 

xrestop pointed out a massive ressource leak in kwin. it seems that on each 
kwin-relevant action (like switching focus, switching desktop), passive grabs 
are pooled, slowing it down and eating memory. 

Below is the patch. I'm not entirely sure why it is necessary, since 
XGrabButton manpage states that it would undo all passive grabs which were 
done before. Apparently it doesn't do that. Maybe its a X11 bug, only god 
knows. 

Reproducable on SuSE9 and confirmed to exist on Debian unstable by Simon. 

Please review. 

Dirk
Attachment (events.diff): text/x-diff, 928 bytes
Permalink | Reply | 2 comments |
headers
Waldo Bastian | 1 Jan 2004 17:34
Picon
Favicon

Re: KDE + Qt/Mac -- how to handle it?


On Thu January 01 2004 16:59, Benjamin Reed wrote:
> > That's just some things that I more or less accidentially spotted. I
> > admit I didn't really dig into every change, and I also admit that I most
> > likely got a few of those things wrong :)
>
> No, I think you were pretty much spot on.  Our changes are clearly still
> in the "hackish" stage.  There's a lot of stuff that needs to be done.

On the risk of stating the obvious. I suggest that once KDE 3.2 is released 
you start feeding your patches piece by piece to kde-core-devel <at> kde.org where 
they can be reviewed/fixed/discussed and then applied to CVS. 

Cheers,
Waldo
--

-- 
bastian <at> kde.org -=|[ KDE: K Desktop for the Enterprise ]|=- bastian <at> suse.com
Permalink | Reply | 0 comments |
headers
Martijn Klingens | 1 Jan 2004 17:39
Picon
Favicon

Re: QMovie leaking lots of pixmap resources

On Thursday 01 January 2004 16:57, Dirk Mueller wrote:
> valgrind is useful in finding memory leaks. You can download it from
> http://valgrind.kde.org/ and run it on your application with
> --leak-check=yes.

Sure, but these are X server resources (pixmaps), as xrestop shows. Can one 
use valgrind for those too?

--

-- 
Martijn
Permalink | Reply | 1 comment |
headers
Martijn Klingens | 1 Jan 2004 17:46
Picon
Favicon

Re: QMovie leaking lots of pixmap resources

On Thursday 01 January 2004 17:39, Martijn Klingens wrote:
> On Thursday 01 January 2004 16:57, Dirk Mueller wrote:
> > valgrind is useful in finding memory leaks. You can download it from
> > http://valgrind.kde.org/ and run it on your application with
> > --leak-check=yes.
>
> Sure, but these are X server resources (pixmaps), as xrestop shows. Can one
> use valgrind for those too?

Also note that it's only leaking memory as long as the window is open. As soon 
as I close the chat window the pixmaps are freed again, I guess by the X 
server.

And while valgrind supports a leakcheck inside a program's execution (instead 
of on exit) I've never tried to find out how to do that. I guess it has 
something to do with including memcheck.h, right?

--

-- 
Martijn
Permalink | Reply | 0 comments |

Gmane