Michael Pyne | 2 Jan 2010 01:52
X-Face
Picon
Favicon

Re: [PATCH] Improve rendering of DocBook documentation

On Wednesday 23 December 2009 02:31:23 Michael Pyne wrote:
> Hi all,
> 
> *snip*
>
> I've tested making handbooks and generating straight HTML (you can see the
> HTML on http://kdesvn-build.kde.org/documentation/) and looked at a few
> handbooks afterwards to see if I left out anything major.  I don't think I
> have but if so, it's just CSS, just let me know.
> 
> So, what are your thoughts?

OK I've had an ack and no negative comments however we are quite a ways past 1 
December 2009 (the documentation/handbook freeze date). This doesn't change 
any of the content of the documentation so it could be argued to be 
permissible under the artwork freeze I guess but I'd like to get a second 
opinion on that. ;)

While I was waiting I made a second revision, which adds a *touch* of text 
shadow to the page title and also forces the page footer to the bottom of the 
page on very short documents.

The aforementioned kdesvn-build docs have been revised to match so you can see 
how it looks in practice, and the patch is attached.

Regards,
 - Michael Pyne
Davide Bettio | 2 Jan 2010 13:05
Favicon

Review Request: Styled selection rect


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2475/
-----------------------------------------------------------

Review request for kdelibs.

Summary
-------

This patch replaces the selection rectangle with a styled selection.

Diffs
-----

  /trunk/KDE/kdelibs/kdeui/colors/kcolorcombo.cpp 1064328 

Diff: http://reviewboard.kde.org/r/2475/diff

Testing
-------

Thanks,

Davide

Davide Bettio | 2 Jan 2010 13:07
Favicon

Review Request: New KColorCombo palette


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2476/
-----------------------------------------------------------

Review request for kdelibs.

Summary
-------

New (and nicer) KColorCombo palette with more colors.

Diffs
-----

  /trunk/KDE/kdelibs/kdeui/colors/kcolorcombo.cpp 1068728 

Diff: http://reviewboard.kde.org/r/2476/diff

Testing
-------

Thanks,

Davide

Davide Bettio | 2 Jan 2010 13:08
Favicon

Re: Review Request: KColorCombo styled selection rect


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2475/
-----------------------------------------------------------

(Updated 2010-01-02 12:08:25.330010)

Review request for kdelibs.

Summary (updated)
-------

This patch replaces the selection rectangle with a styled selection.

Diffs
-----

  /trunk/KDE/kdelibs/kdeui/colors/kcolorcombo.cpp 1064328 

Diff: http://reviewboard.kde.org/r/2475/diff

Testing
-------

Thanks,

Davide

(Continue reading)

Christoph Feck | 2 Jan 2010 13:35
Picon

Re: Review Request: KColorCombo styled selection rect


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2475/#review3557
-----------------------------------------------------------

/trunk/KDE/kdelibs/kdeui/colors/kcolorcombo.cpp
<http://reviewboard.kde.org/r/2475/#comment2824>

    * The QStyleOptionViewItem can contain a widget. Use that to get the style when available.

    * Use PE_PanelItemViewItem to draw the background. grep for this in kdelibs to get examples.

    * Make sure "showDecorationSelected" is true to fix problems with CDE/Motif styles (see bug 164684)

- Christoph

On 2010-01-02 12:08:25, Davide Bettio wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2475/
> -----------------------------------------------------------
> 
> (Updated 2010-01-02 12:08:25)
> 
> 
> Review request for kdelibs.
> 
> 
(Continue reading)

Dirk Mueller | 2 Jan 2010 16:12
Picon
Favicon

ADMIN: Severe Mail Loss since 01-01-2010


Hi, 

The Spam filtering software used on kde.org unfortunately had a Year2010 bug, 
which caused almost all mail to be tagged as spam, and in some cases to be 
rejected/discarded. 

If your mail did not arrive, please send again. Please spread the word to 
other mailing lists if necessary. everything hosted under  <at> kde.org was 
affected.

I'm very sorry about this, I'll test decade-safety of our software for 2020 ;)

Greetings,
Dirk

Frederik Gladhorn | 2 Jan 2010 20:20
Picon
Favicon
Gravatar

Review Request: make Solid::Control::PowerManager::brightness check if a control for the screen is available


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2479/
-----------------------------------------------------------

Review request for kdelibs.

Summary
-------

The brightness functions in solid only check if controls.size() == 0 but not for the right type of control to
be in the list. This leads to crashes in the battery plasma applet on my system (some recent KDE 4.4 change
triggers it).

Diffs
-----

  /trunk/KDE/kdebase/workspace/libs/solid/control/powermanager.cpp 1069076 

Diff: http://reviewboard.kde.org/r/2479/diff

Testing
-------

Thanks,

Frederik

(Continue reading)

Pino Toscano | 2 Jan 2010 23:17
X-Face
Picon
Favicon

Re: critical regression or misconfiguration? Fallback to hicolor icons does not work

Hi,

> On Mac OS X (1) KDE applications don't find their hicolor icons. The
> reason for this is that there is no "index.theme" inside $PREFIX/share/
> icons/hicolor. As soon as such a file is added (for testing I've just
> copied Oxygen's and changed the name) the fallback for missing oxygen
> icons work.

We ship kdebase/runtime/pics/hicolor/index.theme, which is properly installed 
in $PREFIX/share/icons/hicolor.

Otherwise, there's the hicolor-icon-theme[1] freedesktop.org definition which 
provides more or less the same file. (This is also what GNU/Linxu distros 
ship, correctly preferring it to our local copy.)

> Is this a kde bug or do I miss an important dependency which installes
> an icons/hicolor/index.theme?
> 
> (1) Using KDE libs and base-runtime 4.3.4 installed via macports. The
> application in question is Krusader from extragear/utils, also
> installed via macports.

It would appear some file not installed in such packages?

[1] http://icon-theme.freedesktop.org/wiki/HicolorTheme

--

-- 
Pino Toscano
John Layt | 3 Jan 2010 00:17
Gravatar

Adding new 'virtual' methods to KCalendarSystem

Hi,

In KCalendarSystem most methods are virtual to allow each calendar 
implementation to override with their particular calculations as required.  I 
need to add more virtual methods to support new features like Era-based 
calendars.  

The problem is there are no extra slots reserved in the virtual table, and the 
base class is not based on QObject so I can't use the slot trick described on 
TechBase.

I was wondering if instead I could add the virtual methods to the d-pointer 
instead and have each child class override that as required?

I was thinking it would look something like this:

// Base class

class CalBase
{
public:
    CalBase();
    virtual int calcFoo( int y, int m, int d );  // already exists
    int calcBar( int y, int m, int d );  // new 'virtual' method
protected:
    setBaseDpointer( CalBasePrivate * );  // new method
private:
    CalBasePrivate * const d;  // already exists
}

(Continue reading)

Oswald Buddenhagen | 3 Jan 2010 01:02
Picon
Favicon
Gravatar

Re: Adding new 'virtual' methods to KCalendarSystem

On Sat, Jan 02, 2010 at 11:17:53PM +0000, John Layt wrote:
> I was wondering if instead I could add the virtual methods to the d-pointer 
> instead and have each child class override that as required?
> 
yes. qt does that in several places.

> Would it be a bad idea to make the derived classes friends of the base
> to directly access the d-pointer, which might be needed anyway?
> 
qt employs the "protected shared d" technique to save memory
allocations. i also used it in kty/-device.
of course, this isn't particularly OO, either. ;)

> An alternative is to just do all the new implementations in the base
> class and have an if-else-if tree based on calendarType(), but that
> isn't very OO.
> 
that's the last resort.

> Or is there another better way?
> 
non-qobject-based classes should all have a virtual_hook (see kconfig*)
- failure to have it is, uhm, sloppiness. :-P
though this is utterly ugly, so it should be only used for methods
which must be virtual outside the lib, i.e., where the shared d trick
doesn't work.


Gmane