Re: Using KColorScheme in style only (Was: fix frameworks-kactions compile error)
Hi, can anyone who knows about styles/KColorScheme comment on this?
Thanks,
Stephen Kelly wrote:
Kevin Ottens wrote:
On Wednesday 11 April 2012 23:34:18 Stephen Kelly wrote:
[...]
At the center of the questions of what to do with KUrlLabel and
KCapacityBar are the question of what to do about their KColorScheme
dependency. Their use of KColorScheme seems to me like something that
should be handled by the style instead (otherwise, for example,
QProgressBar wouldn't look consistent with a KCapacityBar with its
backgrounds and fill etc). Oxygen may already even handle a KCapacityBar
(I'm not certain):
kde-workspace/kstyles/oxygen{master}$ git grep CapacityBar
oxygenstyle.cpp:CE_CapacityBar( newControlElement(
CE_CapacityBar ) )
oxygenstyle.cpp:if( element == CE_CapacityBar )
oxygenstyle.cpp:fcn = Style::drawCapacityBarControl;
oxygenstyle.cpp:bool Style::drawCapacityBarControl( const
QStyleOption* option, QPainter* painter, const QWidget* widget ) const
oxygenstyle.h:virtual bool drawCapacityBarControl( const
QStyleOption*, QPainter*, const QWidget* ) const;
oxygenstyle.h:QStyle::ControlElement CE_CapacityBar;
KColorScheme is very different from QPalette. It seems to have 4
dimensions that QPalette doesn't have. I'm all for configuration, but I
think it should have an affect in the style, not in the widgets
themselves. Any thoughts?
Would it be possible to remove the use of KColorScheme from these
widgets in general?
I'm unfortunately completely ignorant regarding KColorScheme... I agree
it should probably not leak into our widgets and be used by the styles
only though.
Hugo, any ideas/comment on this? The background is here:
http://thread.gmane.org/gmane.comp.kde.devel.frameworks/473/focus=485
Thanks,
Re: Using KColorScheme in style only (Was: fix frameworks-kactions compile error)
On 04/19/2012 11:27 AM, Stephen Kelly wrote:
Hi, can anyone who knows about styles/KColorScheme comment on this?
Thanks,
Stephen Kelly wrote:
Kevin Ottens wrote:
On Wednesday 11 April 2012 23:34:18 Stephen Kelly wrote:
[...]
At the center of the questions of what to do with KUrlLabel and
KCapacityBar are the question of what to do about their KColorScheme
dependency. Their use of KColorScheme seems to me like something that
should be handled by the style instead (otherwise, for example,
QProgressBar wouldn't look consistent with a KCapacityBar with its
backgrounds and fill etc). Oxygen may already even handle a KCapacityBar
(I'm not certain):
yes. Oxygen does overwrite the default rendering for kcapacitybar.
kde-workspace/kstyles/oxygen{master}$ git grep CapacityBar
oxygenstyle.cpp:CE_CapacityBar( newControlElement(
CE_CapacityBar ) )
oxygenstyle.cpp:if( element == CE_CapacityBar )
oxygenstyle.cpp:fcn =Style::drawCapacityBarControl;
oxygenstyle.cpp:bool Style::drawCapacityBarControl( const
QStyleOption* option, QPainter* painter, const QWidget* widget ) const
oxygenstyle.h:virtual bool drawCapacityBarControl( const
QStyleOption*, QPainter*, const QWidget* ) const;
oxygenstyle.h:QStyle::ControlElement CE_CapacityBar;
KColorScheme is very different from QPalette. It seems to have 4
dimensions that QPalette doesn't have. I'm all for configuration, but I
think it should have an affect in the style, not in the widgets
themselves. Any thoughts?
Would it be possible to remove the use of KColorScheme from these
widgets in general?
In my oppinion, yes.
Oxygen does use kcolorscheme extensively (that's actually one of the
reason why it can't easily be isolated as a Qt only widget style)
I believe it's ok if default rendering of custom kdeui widgets uses Qt
only (QPalette, QStyle)
One can always overwrite the default rendering to benefit from whatever
KDE features you want.
I'm unfortunately completely ignorant regarding KColorScheme... I agree
it should probably not leak into our widgets and be used by the styles
only though.
Hugo, any ideas/comment on this? The background is here:
http://thread.gmane.org/gmane.comp.kde.devel.frameworks/473/focus=485
Thanks,
Review Request: kjs: Implement Array.isArray
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104676/ --- Review request for kdelibs. Description --- kjs: Implement Array.isArray strictly to ECMA Edition 5.1 r6 - 15.4.3.2 Diffs - kjs/array_object.cpp 7538ba1 Diff: http://git.reviewboard.kde.org/r/104676/diff/ Testing --- ecmascript 15.4.3.2 tests Thanks, Bernd Buschinski
Review Request: kjs: Global NaN, undefined and Infinity should be [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104678/ --- Review request for kdelibs. Description --- kjs: Global NaN, undefined and Infinity should be [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false as defined by ecmascript Edition 5.1r6 in 15.1.1.1-3 Diffs - kjs/interpreter.cpp cf1acf1 Diff: http://git.reviewboard.kde.org/r/104678/diff/ Testing --- Confirmed by ecmascript Object.getOwnPropertyDescriptor tests von Global NaN, undefined and Infinity Thanks, Bernd Buschinski
Review Request: kjs: All prototype constructor should be [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104680/
---
Review request for kdelibs.
Description
---
kjs: All prototype constructor should be [[Writable]]: true, [[Enumerable]]:
false, [[Configurable]]: true
As said in ECMA Edition 5.1r6 - 15.1:
Unless otherwise specified, the standard built-in properties of the global
object have attributes {[[Writable]]: true, [[Enumerable]]: false,
[[Configurable]]: true}.
And it is not otherwise specified.
Diffs
-
kjs/interpreter.cpp cf1acf1
Diff: http://git.reviewboard.kde.org/r/104680/diff/
Testing
---
Confirmed by ecmascript tests checking the attributes of
*.prototype.constrictor with Object.getOwnPropertyDescriptor
like
Object.getOwnPropertyDescriptor(Date.prototype, constructor);
Thanks,
Bernd Buschinski
Re: Review Request: KJS: Implement Object.prototypeOf, Object.keys, Object.getOwnPropertyNames
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104511/ --- (Updated April 19, 2012, 8:35 p.m.) Review request for kdelibs. Changes --- Updated Array getOwnPropertyNames to 3 parameter version, so it will work again alone after this patch (the following patch will change it again anyway, but its good to keep it working after every commit) Description --- KJS: Implement Object.prototypeOf, Object.keys, Object.getOwnPropertyNames NOTE: Array was left out on purpose, as currentl imeplementation does not save attributes (next patch will fix this) keysGetOwnPropertyNames requieres to change the JSObject::getOwnPropertyNames implementation, for future use a enum is better than than a bool, maybe there will be more ways to include/exclude properties. All changes for khtml/ecma/ are to silense the -Woverloaded-virtual warnings Diffs (updated) - khtml/ecma/kjs_css.h aba44b8 khtml/ecma/kjs_css.cpp e3e7417 khtml/ecma/kjs_dom.h d0433c3 khtml/ecma/kjs_dom.cpp 5fff7e3 khtml/ecma/kjs_html.h 0f3f544c khtml/ecma/kjs_html.cpp e3da95c khtml/ecma/kjs_scriptable.h af5343c khtml/ecma/kjs_scriptable.cpp 5d4ea68 kjs/JSVariableObject.h a8f01eb kjs/JSVariableObject.cpp b00ef76 kjs/array_instance.h 3f2b630 kjs/array_instance.cpp fe9b8b4 kjs/function.h 3757fe8 kjs/function.cpp 5f39ae6 kjs/object.h 047c242 kjs/object.cpp c19122f kjs/object_object.cpp 986f03f kjs/property_map.h 6b127ff kjs/property_map.cpp b2ff08e kjs/string_object.h e890d52 kjs/string_object.cpp 170e2f7 Diff: http://git.reviewboard.kde.org/r/104511/diff/ Testing --- ecma script daily surfing Thanks, Bernd Buschinski
Re: Pairs going to KDE Edu
Hello, Please find attached suggested patches to fix/improve Windows build. (ps: I'm not in kde-edu mailing list, so this e-mail will probably be blocked there). Thanks, Andrius. 2012/4/17 Albert Astals Cid aa...@kde.org El Dilluns, 16 d'abril de 2012, a les 03:35:51, Aleix Pol va escriure: Hi, Last friday Pairs [1] was moved from playground/edu to kdereview because we want it to be moved to kdeedu. We have been working on it for a while already and we would like it to move to kde edu and to be included in the next KDE release. If someone is interested, please take a look into it and tell us what you think. More problems: * The repo is marked as inactive in projects.kde.org, so scripty doesn't run over it * The desktop file has X-DocPath but you removed the doc * The desktop file has X-Ubuntu-Gettext-Domain=desktop_kdesdk Albert Thanks! Aleix PS: It has a notable artwork lacking that's being worked on, slowly. Although if anybody is interested in joining, we are welcoming people :). [1] https://projects.kde.org/projects/kdereview/pairs 0003-Fix-usage-of-local-file-URLs.patch Description: Binary data 0004-Add-Windows-Mac-application-icon.patch Description: Binary data 0001-Fix-usage-of-local-file-URLs-Whitespace-fixes.patch Description: Binary data 0002-Files-provided-by-Pairs-are-Zip-files.-Changing-from.patch Description: Binary data
