Matthew Woehlke | 1 Dec 02:59 2007
Picon
Picon

Re: Color of tooltip

Sebastian Kuegler wrote:
> For years, on of my personal major nitpicks is the colour of our tooltips. Now 
> this is totally subjective, but for my eyes, the yellow looks misplaced in 
> almost all occurrences. Finally, in KDE4, I can change it. A huge thanks to 
> those who made it possible! (I recall talking with richmoore and Olaf about 
> it during last aKademy, and of course mwoehlke is our colour-hero.)

Thanks :-). Now we just have to wait for Qt 4.4 to be able to change 
QWhatsThis also :-/.

> I'm wondering how chances are that we change the tooltip colour to something 
> which is not yellow, maybe a light grey. Attached patch accomplishes this for 
> me. The screenshot shows how this would look like.
> 
> Any chance this would be accepted?

Not right now... the entire set of default colors is going to go away 
once we pick a new default scheme. Instead, please submit a patch 
against kdebase/workspace/kcontrol/colors/schemes/Steel.colors which is 
currently my preference for the new default and is still likely too 
yellow for your taste :-). (The other schemes currently in svn are 
mostly non-yellow, or if they are yellow it's because it fits the 
overall look decently.)

(If one of my other preferences - namely "any light-on-dark" - wins, it 
certainly won't have yellow :-).)

--

-- 
Matthew
"Any customer can have a car painted any color that he wants...
(Continue reading)

Matthew Woehlke | 1 Dec 03:12 2007
Picon
Picon

Re: Color of tooltip

Matthew Woehlke wrote:
> Sebastian Kuegler wrote:
>> I'm wondering how chances are that we change the tooltip colour to 
>> something which is not yellow, maybe a light grey. Attached patch 
>> accomplishes this for me. The screenshot shows how this would look like.
>>
>> Any chance this would be accepted?
> 
> Not right now... the entire set of default colors is going to go away 
> once we pick a new default scheme. Instead, please submit a patch 
> against kdebase/workspace/kcontrol/colors/schemes/Steel.colors [snip]

Actually, I just made it pale blue, same hue as the selection, as I 
thought it was too yellow also :-).

This brings the grand total of schemes currently in svn that have yellow 
tooltips to one (honeycomb, which is very yellow already)... not 
counting what is currently in kcolorscheme.cpp but will be going away as 
soon as we pick the new default scheme.

--

-- 
Matthew
"Any customer can have a car painted any color that he wants...
...so long as it is black." -- Henry Ford

Allen Winter | 1 Dec 04:12 2007
Picon

Re: kdeutils maintainer? khexedit program unmaintained

On Friday 30 November 2007 14:34:51 Friedrich W. H. Kossebau wrote:
> Hi,
> 
> from http://techbase.kde.org/Schedules/KDE4/4.0_Module_Status#Module_Status I 
> read there is no Release Maintainer for kdeutils. So who decides/cares there? 
> I guess this list, then.
> 
The Release Team, so I'll copy this over to our mailing list.

> With KHexEdit currently there is a tricky situation. Under kdeutils/khexedit 
> live two separate projects, the program KHexEdit and the binary editor plugin 
> (see the subdirs core, gui, parts), project name Okteta*.  I personally only 
> care for Okteta, but not for the program (see footnote why). 
> 
> Right now KHexEdit is roughly ported and runs, but is not fully functional 
> (painting draws outside of PaintEvent, view tabs running wild and crash the 
> program, html/rtf export not working). So not really in release state (yet).
> Two solutions:
> 1. Exclude from release and hope for me getting Okteta ready for the next one.
> 2. Search maintainer and fix KHexEdit.
> 
> I favour #1 (one program to rule things, no conflicts ;) But I understand 
> those who like #2 more, just tell me what you think.
> In case most like #2 more I would blog and mail a maintainer query to Danny 
> for inclusion in the digest.
> 
> So?
> 
> * Both projects share no code, as the plugin was written from scratch. Instead 
> of modifying KHexEdit to make use of the libs, I decided to write a program 
(Continue reading)

Robert Knight | 1 Dec 07:01 2007
Picon

Colors - Performance impact of non-equal inactive and active palettes

Hello,

There has already been some discussion of the performance problems
[1][2] caused by having inactive and active colour palettes for
widgets which are different.  I couldn't find a more recent discussion
on the matter - please point me to it if there is one.

At the time of the original discussion, the whole window changed
appearance when changing between the inactive and active palettes, so
the performance problems were very evident.  Fast forward to November
and the only difference between the inactive and active colour
palettes is the colours used for selected items (
QPalette::highlight() and QPalette::highlightedText() ).  This effect
is quite subtle, without such obvious flicker, but the problem of Qt
repainting the entire widget whenever its active/inactive status
remains.

In QWidget::event() , Qt simply compares the inactive and active
palettes on a WindowActivated or WindowDeactivated event and triggers
a complete repaint if they are different.  This applies to many, many
widgets which look identical whether they are active or inactive
because they don't make use of the highlight colour, or only make
limited use of it under certain circumstances (eg. part of the widget
is an active selection).

On some computers, this problem merely makes applications feel a
little slower than they should do, since it completely negates the
performance benefit which Qt 4's double buffering provides when
switching between windows.  On others (older computers, thin clients
or any other situation involving X over a network) I guess it may
(Continue reading)

Aaron J. Seigo | 1 Dec 08:33 2007
Picon

Re: Colors - Performance impact of non-equal inactive and active palettes

On Friday 30 November 2007, Robert Knight wrote:
> is quite subtle, without such obvious flicker, but the problem of Qt
> repainting the entire widget whenever its active/inactive status
> remains.

erg =( given that it's only used for the selection colour these days anyways, 
i think it's wise if we just didn't go with the different palettes at least 
for 4.0 and see if we can't get some improvements at the Qt level for future 
releases.

--

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

KDE core developer sponsored by Trolltech
Thomas Zander | 1 Dec 09:16 2007
Picon

Re: Color of tooltip

On Saturday 01 December 2007 03:12:36 Matthew Woehlke wrote:
> This brings the grand total of schemes currently in svn that have
> yellow tooltips to one (honeycomb, which is very yellow already)... not
> counting what is currently in kcolorscheme.cpp but will be going away
> as soon as we pick the new default scheme.

Is there a 'Windows' or 'Traditional' colorscheme?
We might be pushing the limits of the amount of change people can grok if 
even these things change...

--

-- 
Thomas Zander
Kleag | 1 Dec 13:57 2007
X-Face
Picon

error building kdelibs

Hello,

Since my yesterday update, I'm not able to build kdelibs. I tried to restart 
from scratch, removing sources, build dir and install dir (except for 
qt-copy) but I still obtain the same link error:

[ 67%] Generating checkXML.1
/home/kde4/kdesvn/build/kdelibs/bin/meinproc4: symbol lookup 
error: /home/kde4/kdesvn/build/kdelibs/lib/./libkio.so.5: undefined symbol: 
_ZN6Strigi14AnalysisResultC1ERKSslRNS_11IndexWriterERNS_14StreamAnalyzerE
make[2]: *** [doc/checkXML/checkXML.1] Error 127
make[1]: *** [doc/checkXML/CMakeFiles/manpage.dir/all] Error 2
make: *** [all] Error 2

Any idea ?

Regards,

Kleag
--

-- 
KsirK - a turn-based strategy game for KDE
http://gna.org/projects/ksirk

KGraphViewer - a GraphViz dot graphs viewer
http://extragear.kde.org/apps/kgraphviewer

Thiago Macieira | 1 Dec 14:04 2007
Picon

Re: error building kdelibs

Kleag wrote:
>/home/kde4/kdesvn/build/kdelibs/bin/meinproc4: symbol lookup
>error: /home/kde4/kdesvn/build/kdelibs/lib/./libkio.so.5: undefined
> symbol:
> _ZN6Strigi14AnalysisResultC1ERKSslRNS_11IndexWriterERNS_14StreamAnalyze
>rE

This is not a build error. This is a local error.

You built libkio against one version of Strigi but you're linking against 
another, older version.

Don't do that. If you don't know why that happened, then remove all but 
one versions of Strigi in your system.

--

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

Re: error building kdelibs

Thiago Macieira wrote:
>You built libkio against one version of Strigi but you're linking
> against another, older version.

I meant that you're running against an older version.

>
>Don't do that. If you don't know why that happened, then remove all but
>one versions of Strigi in your system.

--

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Kleag | 1 Dec 15:36 2007
X-Face
Picon

Re: error building kdelibs

Le samedi 1 décembre 2007, Thiago Macieira a écrit :
> Kleag wrote:
> >/home/kde4/kdesvn/build/kdelibs/bin/meinproc4: symbol lookup
> >error: /home/kde4/kdesvn/build/kdelibs/lib/./libkio.so.5: undefined
> > symbol:
> > _ZN6Strigi14AnalysisResultC1ERKSslRNS_11IndexWriterERNS_14StreamAnalyze
> >rE
>
> This is not a build error. This is a local error.
>
> You built libkio against one version of Strigi but you're linking against
> another, older version.
>
> Don't do that. If you don't know why that happened, then remove all but
> one versions of Strigi in your system.
Yes, I understand the problem... Some time ago, I installed the task-kde4 
metapackage of mandriva 2008 to ensure having all the dependencies. But it 
seems I forgot to uninstall strigi from there, 

Thanks a lot.

Kleag

--

-- 
KsirK - a turn-based strategy game for KDE
http://gna.org/projects/ksirk

KGraphViewer - a GraphViz dot graphs viewer
http://extragear.kde.org/apps/kgraphviewer

(Continue reading)


Gmane