blend function urgently needed in kdelibs

[Aaron J. Seigo]

On Monday 21 May 2007, Alex Merry wrote:
> On Monday 21 May 2007, Matthew Woehlke wrote:
> > Andreas Pakulat wrote:
> > > On 21.05.07 14:31:45, Matthew Woehlke wrote:
> > >> KColor blend(const KColor& c1, const KColor& c2,
> > >>              double k = 0.5, double r = 0.5, SPEC cs = CS_RGB,
> > >>              int flags = BLEND_NORMAL, int cmask = 0x0000FFFF);
> > >>
> > >> Can someone PLEASE suggest where I can put such a thing? (Due to
> > >> lack of prior response, if I don't hear back by next Monday I'm
> > >> going to /pick/ somewhere and people can bitch about it.)
> > >
> > > I also think kdefx would be more apropriate than kdeui/colors, the
> > > latter one is mainly for color-related widgets, while the former
> > > has kstyle and co, and I guess KStyle would need such a thing (or
> > > am I wrong there?)
> >
> > No, kdeui/colors is definitely wrong, but kdefx seems a little heavy
> > for how basic I think of blend() being, which is why I'm eying
> > kdeui/kernel. What do others think?
>
> Note that kdeui links with kdefx, so, if anything, kdefx underpins
> kdeui.

unfortunately, kdefx is also past its prime. zack's kimagefx is a much more 
interesting approach to most of what kdefx does.

> Although kdeui/kernel provides non-widget 
> things, they're interaction-with-X11/OS/etc style classes, which KColor
> doesn't really fit into.

right. it has nothing to do with "widgetness". things in kdeui require a GUI 
(e.g. QtGui). they are then further divided into topics, with widgets/ and 
util/ being catch-alls for the things which don't have a larger group of 
files to put into a single topic.

> If it were to go into kdeui, I'd say kdeui/util.

can someone explain to me why the "organized by topic" directory structure is 
difficult to understand? because apparently it is and i'm not sure why. maybe 
it just isn't explained well enough. hm.

let me try and explain it this way:

if you are going into kdeui for the first time and looking for a class called 
KColor and it is in kdeui, would you look first in colors/, kernel/ or util/? 

the directories are topical. it has nothing to do with widgets or not. look at 
what is in colors/: it includes color related *data* even.

put another way:

if you were to working on KColor, what are the most likely other files you'd 
want or need to be looking at?

> PS [and rather OT]: is it just me, or kdefx a bit random?  Is there a
> reason for it being a separate library, rather than a subdirectory in
> kdeui?

dlopen to avoid dep on kdeui.

> And KCPUInfo just doesn't seem to fit - although it's there purely for
> the benefit of KImageEffect, it's also an exported interface, and
> linking against libkdefx for KCPUInfo certainly isn't intuitive...

cpuinfo is indeed an artifact.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070521/ebb9d9bd/attachment.sig>