headers
Matthew Woehlke | 1 Jun 2007 01:37
Picon
Gravatar

Re: changing KGraphicsUtils?

Michael Pyne wrote:
> On Thursday 31 May 2007, Thomas Zander wrote:
>> It doesn't help anyone to state your opinion on it with a sad smiley and
>> it certainly doesn't add any value to the method.  Its just being nasty
>> at your fellow programmers. Please don't do that.
> 
> It adds value by identifying the method for future optimization efforts 
> (although profiling is still the best way).

In terms of demonstrable speed difference, I posted data a while back 
indicating that the current blendColors() is 20x-50x slower than 
KColor::blend(). I would expect mix() to be comparable to, or slightly 
faster than KColor::blend(). At minimum if blendColors()/overlayColors() 
stays around we could optimize the default case, however as the part of 
the comment Thomas didn't quote indicates, ATM using QPainter is the 
only way to be 110%* sure the behavior is the same as Qt.

(* since I believe the blend modes are based on well-known algorithms, I 
don't expect them to change, but...)

--

-- 
Matthew
"943. I am not Bjorn of Borg."
  -- from 975 things Mr. Welch can no longer do in an RPG
http://theglen.livejournal.com/16735.html
Permalink | Reply | 0 comments |
headers
Thiago Macieira | 1 Jun 2007 01:56
Picon
Favicon

Re: [apaku <at> gmx.de: Threadsafe access to a KConfig object]

Andreas Pakulat wrote:
>So we'd like to get some ideas as to how we can make the access to the
>project configuration threadsafe, without letting each plugin know what
>the config files are that are used to create the KConfig object (the
>setup code should stay internal to the project class).

Protect it with a mutex or a RWLock.

--

-- 
  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 | 2 comments |
headers
Andreas Pakulat | 1 Jun 2007 02:14
Picon
Picon
Gravatar

Re: [apaku <at> gmx.de: Threadsafe access to a KConfig object]

On 01.06.07 01:56:45, Thiago Macieira wrote:
> Andreas Pakulat wrote:
> >So we'd like to get some ideas as to how we can make the access to the
> >project configuration threadsafe, without letting each plugin know what
> >the config files are that are used to create the KConfig object (the
> >setup code should stay internal to the project class).
> 
> Protect it with a mutex or a RWLock.

Right, I forgot to add that we're trying to find a way that doesn't
involve having

project->lockConfiguration();
project->projectConfiguration();
project->unlockConfiguration();

each time we try to access the project configuration.

Andreas

--

-- 
You have a will that can be influenced by all with whom you come in contact.
Permalink | Reply | 1 comment |
headers
Thomas Zander | 1 Jun 2007 02:18
Picon
Favicon

Re: changing KGraphicsUtils?

On Thursday 31 May 2007 17:40:42 Matthew Woehlke wrote:
> > I'd like to keep it to graphicsUtils; its not a mismatch as colors
> > are certainly a part of graphics utils.
>
> Well, yes, but ColorUtils is more specifically descriptive. If we keep
> it GraphicsUtils, that to me implies it should be merged with kdefx?

Not sure why, I'd like to not argue on every little detail; do you have 
major problems with KGraphicsUtils?

--

-- 
Thomas Zander
Permalink | Reply | 2 comments |
headers
Thomas Zander | 1 Jun 2007 02:23
Picon
Favicon

Re: changing KGraphicsUtils?

On Thursday 31 May 2007 17:52:18 Matthew Woehlke wrote:
>  I don't
> consider providing only the one method a fair means of gathering 'real
> use data'.

Why not?

The idea is that if the methods warrent this we change the method 
signature anyway. What is the use of doing that now and agreeing to do it 
again in some weeks??

Can you agree to keep the current API for some time and see who uses it to 
come up with a proper method designed based on usage of the concepts?

I'd really like to conclude emailing on this topic, its getting immensely 
repetitive and nonconstructive in that I can't possibly see a long term 
right API coming out of continuing discussions based on personal opinions 
instead of practice inspired use cases.
--

-- 
Thomas Zander
Permalink | Reply | 0 comments |
headers
Thomas Zander | 1 Jun 2007 02:29
Picon
Favicon

Re: changing KGraphicsUtils?

On Thursday 31 May 2007 18:01:48 Matthew Woehlke wrote:
> Thomas Zander wrote:
> > * Your patch leaves in code of me/zack but you remove the copyright
> > lines. That's [censored], please don't.
>
> I'm sorry you feel that way, but I am also confused; I still see both
> your names listed as copyright holders

Lets not get hung up on this issue; I just see
- * Copyright (C) 2007 Thomas Zander <zander <at> kde.org>
- * Copyright (C) 2007 Zack Rusin <zack <at> kde.org>

in a file that just adds some code. Thats not how we do things, so I'd ask 
you to retain the copyright of the file 'as is. Thanks.

> > * Your patch has a comment like this one;
> >
> >> >+   // This isn't exactly fast  :-(
> >
> > [snip] Please don't do that.
>
> Well, it /is/ much slower than it needs to be for the common use case.
> Anyway, is this better?
>
>      // This isn't the fastest way, but should be "fast enough".
>      // It's also the only safe way to use QPainter::CompositionMode

I'm sure you are capable of writing constructive messages and not let any 
negative opinion show through. The new example is already a bit better, 
yes.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Zander | 1 Jun 2007 02:38
Picon
Favicon

Re: changing KGraphicsUtils?

On Friday 01 June 2007 00:47:17 Michael Pyne wrote:
> > * We are still / again doing design by committee. We really need
> > usages of the API so we have a set of proper use cases.  I would (re)
> > request that we wait for the codebase to actually gain those before
> > we make decisions on how the method should react.  There just are too
> > many different opinions on what is best.
>
> I thought we already had input from developers saying they needed a
> function like mixColors()?  In the end this is all still about blending
> but the current implementation of blendColors() is apparently still
> lacking. :)

sure, nobody is arguing that.

What is wrong with having _several_ implementations using some blending of 
colors to figure out what the best behavior is?
I'm confused what the big haste is. Why do you guys want to settle this 
_now_?? (which I conclude from  you continuing this thread)

We traditionally have 3 usages of some code before we find something 
eligible to import into KDELibs. For a reason.
I'd really like to know why you guys are resisting the proposed action of 
letting the dust settle for a while now.
--

-- 
Thomas Zander
Permalink | Reply | 5 comments |
headers
Alexander Neundorf | 1 Jun 2007 03:33
Picon
Favicon

Making kdelibs depend on Boost, Was: Re: FindKdepimLibs.cmake

On Thursday 31 May 2007 10:19, Allen Winter wrote:
> On Thursday 31 May 2007 10:14:32 am Christian Ehrlicher wrote:
> > Von: Allen Winter <winter <at> kde.org>
> >
> > > On Wednesday 30 May 2007 5:56:05 am Aaron J. Seigo wrote:
> > > > is that the right approach, is there a better/preferred mechanism?
> > >
> > > I don't believe that any libs in kdelibs nor kdepimlibs should be
> > > optionally built.
> > > We need to either 1) make boost a hard dependency or 2) copy parts of
> > > boost
> > > into kdepimlibs or 3) ??
> >
> > Syndication was made optional because I wanted to build kdepimlibs
> > without boost on win32 at this time. We needed some time to get some
> > (working) boost headers. As we now have them, it can get a hard
> > dependency.
>
> Ok, thanks Christian.
>
> I will make boost a hard dependency.

When ? 
The last time somebody suggested to make boost a hard dependency it was 
rejected. So this should be at least discussed on this list.

Bye
Alex
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Pyne | 1 Jun 2007 03:46
X-Face
Favicon

Re: changing KGraphicsUtils?

On Thursday 31 May 2007, Thomas Zander wrote:
> What is wrong with having _several_ implementations using some blending of
> colors to figure out what the best behavior is?

i.e. have the other implementations sit out of kdelibs?  I'm not opposed to 
that (and indeed, that is currently the situation).

> I'm confused what the big haste is. Why do you guys want to settle this
> _now_?? (which I conclude from  you continuing this thread)

I no need for a huge push to get it into kdelibs, but I don't see a reason to 
hold it back just to see how overlayColors() turns out because I'm at least 
under the impression that we already have feedback that it is insufficient.  
This series of threads has been going on forever, I think it would be helpful 
if we can have people speak up at let us know *exactly* what they need with 
regards to color blending.

We have had a lot of people pipe up saying that colorspace foo is awesome, 
etc. etc. but I think we should focus on the problem of blending colors.  So 
who needs a blending function, and what did they need from it?  What I gather 
so far is:

* Usability improvements (blending would be the underlying code for lighten(), 
darken() and otherwise adjusting color schemes).
* Use in widget styles.  But perhaps this should be in KStyle then.
* And I've already forgotten what else.  But if you need this feature, don't 
just let implementors hash it out (the design-by-committee), you need to 
speak up too! :)

> We traditionally have 3 usages of some code before we find something
(Continue reading)

Permalink | Reply | 4 comments |
headers
Matt Rogers | 1 Jun 2007 03:55
Picon
Favicon
Gravatar

Re: [apaku <at> gmx.de: Threadsafe access to a KConfig object]

On Thursday 31 May 2007 19:14, Andreas Pakulat wrote:
> On 01.06.07 01:56:45, Thiago Macieira wrote:
> > Andreas Pakulat wrote:
> > >So we'd like to get some ideas as to how we can make the access to the
> > >project configuration threadsafe, without letting each plugin know what
> > >the config files are that are used to create the KConfig object (the
> > >setup code should stay internal to the project class).
> >
> > Protect it with a mutex or a RWLock.
>
> Right, I forgot to add that we're trying to find a way that doesn't
> involve having
>
> project->lockConfiguration();
> project->projectConfiguration();
> project->unlockConfiguration();
>
> each time we try to access the project configuration.
>
> Andreas

if that's what we have to do, that's what we have to do.
--

-- 
Matt
Permalink | Reply | 0 comments |

Gmane