Starting with KDE Frameworks 5, we will release Frameworks, Workspaces and
Applications each with their own release cycles. Each of these releases
would
be a set of tarballs of the latest stable versions of the application (or
codebase in more general).
As an example, Frameworks could
This looks wrong to me; strictEqual is used for ===, which is defined
in 11.9.6, and doesn't do any freaky deviations from IEEE FP. You'll
likely need a separate version for SameValue proper.
On 3/21/12, Bernd Buschinski b.buschin...@googlemail.com wrote:
Thanks for the patch.
I don't think that this is a good approach. Spec-wise, what permits
keywords to be used in a few spots is not just the production
MemberExpression ::= MemberExpression . IdentifierName and likewise
for CallExpression (where IdentifierName matches both our
IdentifierOrKeyword
Please don't tell me a binary incompatible change in a stable branch
is seriously being considered.
Flabbergasted,
Maks
On 9/21/11, Gorosito Gonzalo xgonz...@gmail.com wrote:
Hi guys,
Just add this to your .kdesrc-buildrc file, right before the
kde-workspace module-set:
module-set
Please also note that I will add a runtime requirement to Mesa 7.11 as I
have here on my system
the start of the Wayland port which will be in 4.8 and requires Mesa 7.11.
Why would wayland support have any effect on runtime dependency on X11?
* all new features will be developed using the recommended git workflow
(pending publication; Cornelius is working on that one);
Those rules might seem like a strong departure from what we're used to. On
the other hand, if you look at them closely, they are merely making explicit
changes to
Testing.
If everyone is working on branches on cool new stuff, the release will be crap.
On 5/17/11, Alexis Ménard men...@kde.org wrote:
Hello,
Not sure this was discussed before but I'd like to bring the topic for
discussion.
Now that KDE moved to git it seems we still have old habits
I am probably being a bit selfish here, but I don't see how we can
ever build on a toolkit that requires OpenGL ES2.0 level hardware.
That would leave many machines that currently run KDE4 solidly (e.g.
my laptop) unable to run KDE5 for no good reason. I doubt it's the
only one out there with a
1) Does this actually fix anything? Did you do any testing?
2) 'like Gecko' was added by Apple guys for a very good reason (UA sniffing)
3) It would be incorrect to add xhtml accepts to khtml's accept-type.
XHTML parsing is buggy, and isn't really worth prioritizing fixing (on
accounts on
erf; two dependencies in kdelibs on KTextEditor. ok, that makes it a no go
then ... hm.. looking at it, only khtml has a build-time dependency on it.
if
the texteditor part isn't available (or the source of the crash even? :)
what
does the debugger do at that point?
Pop up an error message
On 2/1/11, Andreas Pakulat ap...@gmx.de wrote:
On 01.02.11 19:49:10, Albert Astals Cid wrote:
No, the natural fix is to make the dependency chain proper, i.e. KTE
depends on kdelibs, khtml depends on KTE+kdelibs. That means khtml
cannot be part of kdelibs anymore if KTE is not part of kdelibs
Except that most (all?) of kdelibs is LGPL, not GPL. So using it for
making money/in closed source apps is possible right now under certain
conditions.
Except that Nokia would require giving them additional rights (full
rights to do whatever they want with the code), so he was right ---
the
12 matches
Mail list logo
