headers
Andreas Pakulat | 1 Jan 2008 11:41
Picon
Picon
Gravatar

Re: Making KCoreConfigSkeleton::useDefaults() virtual

On 31.12.07 17:50:07, Andreas Pakulat wrote:
> Hi,
> 
> I know 4 days to the release tagging, BiC changes have long been done
> with and stuff. 
> 
> Unfortunately I just now looked again deeper into KDevelop's project
> configuration stuff due to a bug in the cmake plugins usage of it.
> 
> What I found is that KCoreConfigSkeleton::useDefaults advertises itself
> as being overrideable and should be overridden in subclasses if special
> cases are needed an usrUseDefaults is not enough. This is the case for
> KDevelop. 
> 
> Thus I'd like to make that function virtual ASAP. Its SC and no
> lxr.kde.org didn't find any code that subclasses and overrides
> useDefaults currently so no code is affected by that change.
> 
> How are my chances?

Before I forget it, I'm going to have no internet connection (or only
once a day or something like that) the next 4 days (starting in a few
hours). So if there are a few more non-objecting commits, please someone
commit the attached patch. Thanks.

Andreas

--

-- 
You have no real enemies.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Zack Rusin | 1 Jan 2008 16:34
Picon
Favicon

Re: [patch] cosmetic fix for KPlotWidget

On Monday 24 December 2007 08:49:56 am David Faure wrote:
> On Tuesday 04 December 2007, Zack Rusin wrote:
> > so lets try this again, but this time with the attached
> > example. the example illustrates:
> > a) how to properly snap primitives (within the DRAW_GOOD_SNAPPING) - of
> > course as i repeated a few times - this is vector graphics no amount of
> > snapping will solve all the cases but this one is the closest,
> > b) how not to snap, which is what was committed (within the
> > DRAW_WRONG_SNAPPING)
> > c) why "b" is wrong and how it breaks (within the MESS_UP_SNAPPING)
> > d) that the coordinate systems do match, it's just that the the aliased
> > one rounds up towards ceil (with SHOW_WHERE_ALIASED_COORDINATES_START)
> >
> > i think this should answer almost all the questions posed in this thread.
> > what it doesn't answer is why it was done this way but life has its
> > mysteries and the sooner we learn to deal with them the better.
>
> Hi Zack,
> Thanks for this example.
> To understand it better I made it interactive, so that one can now toggle
> checkboxes and see the effect immediately, rather than modify
> code+compile+run+open png file :) New example attached, I hope this helps
> others understanding it as well.

Hey, very nice :)

Looking back I'm not sure if we actually point out in the documentation what's 
up with the stroking voodoo.

So in a list:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aaron J. Seigo | 1 Jan 2008 20:15
Picon
Favicon
Gravatar

Re: [PATCH] Nicer category headers in SystemSettings

On Sunday 30 December 2007, Aurélien Gâteau wrote:
> - Reduce the header bottom line to a 1 pixel thin line

it would be nice if QStyle provided access to a styled separator line (without 
resorting to abusing one of the widget's Panel PE's, that is)

> - Remove font enlarging for the header title

i wish you'd attached a screenshot, really, since this is probably one of 
those things that's hard to comment on without seeing it. however, i'd bet 
that Anders is correct here and that the title might blend in far too much 
without some differentiation between the items. i'd have to see it in action 
though, but i just now finished building kdelibs and really don't have time 
today to play with these things (but i wish i did =)

> - Align the left of the title with the beginning of the bottom line

this would be a nice thing imho, yes.

--

-- 
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
Permalink | Reply | 0 comments |
headers
Aurélien Gâteau | 1 Jan 2008 22:54
Picon
Favicon
Gravatar

Re: [PATCH] Nicer category headers in SystemSettings

Anders Lund wrote:

> On Monday 31 December 2007, Aurélien Gâteau wrote:
>> 1 pixel border lines are really common on the web and in other
>> application. It's only a decoration, so I don't think it's that much of a
>> problem if some people can't see it. As long as they can see the category
>> text.
> 
> If the text layout of the category text doesn't differ from that of the
> items it would be the only hint that the header has a different meaning
> than the item texts.

The title still differs from other items: it uses a bold font and its
alignment is quite different. As Aaron pointed out, it would probably be
easier to evaluate with a screenshot. Here it is:

http://img217.imageshack.us/img217/4295/systemsettingscategorieol1.png

Aurélien
Permalink | Reply | 2 comments |
headers
Aaron J. Seigo | 1 Jan 2008 23:17
Picon
Favicon
Gravatar

Re: [PATCH] Nicer category headers in SystemSettings

On Tuesday 01 January 2008, Aurélien Gâteau wrote:
> Anders Lund wrote:
> > On Monday 31 December 2007, Aurélien Gâteau wrote:
> >> 1 pixel border lines are really common on the web and in other
> >> application. It's only a decoration, so I don't think it's that much of
> >> a problem if some people can't see it. As long as they can see the
> >> category text.
> >
> > If the text layout of the category text doesn't differ from that of the
> > items it would be the only hint that the header has a different meaning
> > than the item texts.
>
> The title still differs from other items: it uses a bold font and its
> alignment is quite different. As Aaron pointed out, it would probably be
> easier to evaluate with a screenshot. Here it is:
>
> http://img217.imageshack.us/img217/4295/systemsettingscategorieol1.png

thanks =)))

i'll just note what i discovered the hard way with kickoff: with some fonts 
bold does not look very different from non-bold =( that said, i doubt that 
will be a big problem here. the screenshot shows how well it stands out given 
the line and indent of the icons.

some semi-random thoughts: that divider line could perhaps use a less bold 
colour than QPalette::Text, e.g. Mid or even MidLight. it would take more 
visual emphasis off of those lines which right now look pretty stark ... and 
technically all that colour stuff should probably be ported over to 
KColorScheme but that's a completely different matter and hardly as critical
(Continue reading)

Permalink | Reply | 1 comment |
headers
Fathi Boudra | 1 Jan 2008 23:38
Picon

Fwd: Latest KDM seems to kill X

Hi,

This is a forwarded mail sent to ossi.
He seems on vac. or not available atm.
Someone could confirm the bug ?

> We are currently working on a snapshot of KDE 4 and noticed the following
> problem: When starting KDM X seems to crash.
>
> We experience the problem with Xserver-Xorg 7.2 and 7.3.
> Attached you find a log file.
>
> Do you have any idea how to fix the issue?
>
> The problem lies in kdm/kfrontend/kgreeter.cpp Reverting it to rc2 fixed
> the X crash, but themes are broken now (another bug).

cheers,

Fathi
Attachment (kdm.log.gz): application/octet-stream, 8072 bytes
Permalink | Reply | 501 comments |
headers
Rafael Fernández López | 2 Jan 2008 02:21
Picon
Favicon
Gravatar

KDE/kdebase

SVN commit 755674 by ereslibre:

Better looking categories. Thanks to Aurélien Gâteau for the original patch.

CCMAIL: kde-core-devel <at> kde.org

 M  +26 -12    apps/dolphin/src/dolphincategorydrawer.cpp  
 M  +1 -1      apps/dolphin/src/dolphincategorydrawer.h  
 M  +5 -5      apps/dolphin/src/kcategorizedview.cpp  
 M  +11 -30    apps/dolphin/src/kcategorydrawer.cpp  
 M  +1 -1      apps/dolphin/src/kcategorydrawer.h  
 M  +5 -5      workspace/systemsettings/kcategorizedview.cpp  
 M  +10 -29    workspace/systemsettings/kcategorydrawer.cpp  
 M  +1 -1      workspace/systemsettings/kcategorydrawer.h  

--- trunk/KDE/kdebase/apps/dolphin/src/dolphincategorydrawer.cpp #755673:755674
 <at>  <at>  -118,9 +118,9  <at>  <at> 

     QPainterPath path;
     path.addRect(option.rect.left(),
-                 option.rect.bottom() - 2,
+                 option.rect.bottom() - 1,
                  option.rect.width(),
-                 2);
+                 1);

     QLinearGradient gradient(option.rect.topLeft(),
                              option.rect.bottomRight());
 <at>  <at>  -134,15 +134,15  <at>  <at>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rafael Fernández López | 2 Jan 2008 02:22
Picon
Favicon
Gravatar

KDE/kdelibs/kutils

SVN commit 755675 by ereslibre:

Better looking categories. Thanks to Aurélien Gâteau for the original patch.

CCMAIL: kde-core-devel <at> kde.org

 M  +3 -16     kpluginselector.cpp  

--- trunk/KDE/kdelibs/kutils/kpluginselector.cpp #755674:755675
 <at>  <at>  -78,7 +78,6  <at>  <at> 
     pluginDelegate->setSeparatorPixels(8);

     QFont title(parent->font());
-    title.setPointSize(title.pointSize() + 2);
     title.setWeight(QFont::Bold);

     QFontMetrics titleMetrics(title);
 <at>  <at>  -806,7 +805,6  <at>  <at> 
     QFont previousFont(painter->font());
     QFont configureFont(painter->font());

-    title.setPointSize(title.pointSize() + 2);
     title.setWeight(QFont::Bold);

     if (index.internalPointer())
 <at>  <at>  -968,16 +966,15  <at>  <at> 

         QFont painterFont = painter->font();
         painterFont.setWeight(QFont::Bold);
-        painterFont.setPointSize(painterFont.pointSize() + 2);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Aaron J. Seigo | 2 Jan 2008 02:37
Picon
Favicon
Gravatar

changing the parent of a KConfigGroup

hi...

working on plasma stuff today i had the need to move a config group to a new 
location in the file. i either had to descend through the potential group 
hierarchy and copy over the entries one by one and then remove the old group, 
which all seemed rather clumsy, or else just change the parent group. 
unfortunately for me (and for dragging plasmoids between containments in 
plasma) there is no way to change the parent group of KConfigGroup.

i figured "how hard could it be?" the attached patch makes this more or less 
work, but i need some cosult with those who have been working on KConfigGroup 
stuff lately, in particular with how it relates to the internal entry map ...

known limitations:

- you can't move KConfigGroups between KConfigs (as noted in the apidox on the 
new method); mostly this is because i'm really unsure what the implications 
of changing the mOwner or sOwner in a KConfigGroup would be and haven't 
researched it thoroughly yet; what i have seen so far tells me it would be a 
bit non-trivial. it would be cool if this limitation was also removed, but 
this patch at least suffices for my simple needs.

- reparent() may not be the best of names; anyone have a better idea?

- KConfigGroup::entryMap, readEntry, etc prior to a sync and re-load is almost 
certainly broken with this patch after a reparent() as KConfigGroup just 
passes in the fullName() of the group to the KConfig object to fetch these 
things. it works for me because i'm recreating the config object as needed, 
but will break in situations where the same KConfigGroup is reparented then 
used again. however, i'm not sure how to re-jig the entry map in KConfig as
(Continue reading)

Permalink | Reply | 22 comments |
headers
Rafael Fernández López | 2 Jan 2008 04:09
Picon
Favicon
Gravatar

Bug #154819 and settings:// protocol cleaning

Hi all,

Wondering if the fix proposed for the bug is right or not... and if we  
could commit it before the tagging if it was a clean patch.

When trying this patch, I saw that settings:// was pretty  
unmaintained. I have worked on a patch for it, and I'd like to know if  
I can commit it:

http://media.ereslibre.es/2008/01/kdebase-settingsprotocol.diff

And the patch I'm not sure if it is fine or not:

http://media.ereslibre.es/2008/01/kdelibs-settingsprotocol.diff

Well, that's all for now... HAPPY NEW YEAR !!

Bye,
Rafael Fernández López.
Permalink | Reply | 0 comments |

Gmane