In data domenica 31 agosto 2014 19:52:34, Roman Bysh ha scritto:

A lot of new users do not know that KDE4 and KDE5 should not be installed and run on the same partition.

First and foremost: there is no KDE5. ;) Secondly, the wording is probably inaccurate: - KDE Frameworks 5 (the libraries) can happily coexist with the 4.x kdelibs; - Plasma 5 (the workspace) can *not* coexist with the 4.x workspace, meaning that there is a conflict (one overwrites the other), so rather than "should not", one should say "can't" - KF5-based applications: this is a case-by-case basis. Also, no KF5 based application has had a real release yet (most are snapshots offered in KDE:Unstable:Frameworks). -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

In data lunedì 1 settembre 2014 08:43:10, Timothy Butterworth ha scritto:

like what happened with KDE4 when it started shipping too early in the mainline distros.

The workspace (4.x version) is in long-term support mode until the second half of next year IIRC. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

On 09/01/2014 10:37 AM, Raymond Wooninck wrote:

However we should remember that KF5 is different in its releases than KDE4. KF5 will have three independent releases (Framework, Plasma and Applications).

Is that in time or space? By that I mean (time) First we get framework, with whatever compatibility with the extant KDE4 applications applies), then we get Plasma, ditto, and finally application are, somehow, upgraded. I can't say I feel comfortable with that, certainly not the way I've expressed it, so correct me if I'm interpreting the ambiguity of your statement in a manner too far from reality. But my reality is the applications. Frameworks are cool; eye candy is cool, but its all those hundreds of other applications that let us get our work done, those of us that are not focused primarily on development. I'm not besmirching developers, far from it, but the handling of the KDE3-> conversion went badly. I do understand that FOSS is about a community and there is a need to throw out the pre-alpha, alpha, post-alpha, pre-beta, bet to the community and the community should try them out and report not only bugs and boundary values but feedback to the developers what are good and bad ideas, directions, and what gaps exists. Yes we had all that with KDE4, but it was very abrupt and alienated many people by pulling KDE3 away. The "in space" might be, for example, separate repositories for each of those. I can see the logic behind such a move.

The Framework components has been worked on already since the moment that kdelibs4 reached LTS (around KDE 4.9/4.10) and work started on Plasma after KDE 4.11 release. Only recently we see that porting work for applications have started. So we already have a different starting point than the KDE3 -> KDE4 transition.

Yes, but you are still going to need people who move and adopt it, and quite frankly postings so far leave me a bit confused about how the transition will occur from my POV as an early-middle-late adopter. Perhaps a digram on a web page, or a series of diagrams would help us poor end-users. Please: do treat us kindly. Even those who like me gave up on KDE3 and don't reminisce about how great KDE3 was still remember the bruised of adopting KDE4. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 09/01/2014 11:58 AM, Luca Beltrame wrote:

In data lunedì 1 settembre 2014 11:45:19, Anton Aylward ha scritto:

...

Is that in time or space?

They simply have different time-based release schedules. Frameworks have a 1 month release schedule, Plasma 5 has a 3 month release schedule. They're not necessarily sequential (although work is done to prevent overlaps).

Is this illustrated (as in time-chart) somewhere rather than words-words-words?

Plasma 5 had to release past the first version of KF5 simply because, obviously, it depended on it.

Diagram of dependencies for those of us for whom all this is not "obvious", please.

...

applications. Frameworks are cool; eye candy is cool, but its all those

Frameworks are not simply "cool". They are the basis for everything else, and they solve a real problem, the fact that you needed the whole kdelibs even for just one feature.

From the pov of the developers, frameworks are much more interesting

than the old, boring ho-um of making sure that applications work under the new scheme, recompiling, changing library definitions in makefiles, #include lines, etc to new ones, Frameworks involve creativity. thought. That's cool. Applications are boooooring. BTDT. Quit a job rather than spend ho-hum days checking all the old apps worked with the new release.

...

hundreds of other applications that let us get our work done, those of

Those will take time to get ported - and the 4.x equivalents will stay until they are.

Are they fully compatible? Has anyone - ho-hum - checked? If so, why do they need to be ported?

...

The "in space" might be, for example, separate repositories for each of those. I can see the logic behind such a move.

Actually applications and libs are already split over a number of repositories (Plasma 5 by itself is made up by software coming from several different repos).

Diagrams and trees PLEASE!

The big message is that KDE (the community) will no longer make "monolithic" releases, but libs, workspace ("the desktop") and applications will use different release schedules.

Sounds like its going to be confusing for a lot of people, most notably the poor end users like me. Diagrams would help immensely! -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

In data lunedì 01 settembre 2014 14:02:40, Anton Aylward ha scritto:

Is this illustrated (as in time-chart) somewhere rather than words-words-words?

As we had 2 releases of KF5 and 1 Plasma 5 release, and no KF5 applications yet, not sure I can do more than that.

Diagram of dependencies for those of us for whom all this is not "obvious", please.

Dependency diagrams, as shumski point out, make sense only for packagers or developers. But in short: /Applications KF5 (libs) \Plasma 5

#include lines, etc to new ones, Frameworks involve creativity. thought. That's cool. Applications are boooooring.

I don't see the point of sarcasm. The idea is to increase use of KDE software in the larger Qt ecosystem. I hardly think a modularization is a bad idea. Also this means that applications can have more fine-grained dependencies.

BTDT. Quit a job rather than spend ho-hum days checking all the old apps worked with the new release.

KF5 is done to minimize API and ABI (binary compatibility) breakage, but it is *not guaranteed*. Just like Qt 5 is not compatible with Qt 4. So, at least by the way you wrote this, it is not possible by design.

Are they fully compatible? Has anyone - ho-hum - checked? If so, why do they need to be ported?

They need to be ported because API and ABI changed, stuff has been deprecated, etc. Also, Qt includes new things contributed by KDE, which means that some old kdelibs specific bits need to be removed. Again: Qt5 is binary incompatible with Qt4.

Sounds like its going to be confusing for a lot of people, most notably the poor end users like me.

Actually the bulk of the work stays on the shoulder of the developers (coordinating this is not trivial) and packagers (track deps, repos, etc). At least in openSUSE we'll do our best to ensure the change is transparent to the end users. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

On 09/01/2014 02:14 PM, šumski wrote:

On Monday 01 of September 2014 20:02:40 Anton Aylward wrote:

...

On 09/01/2014 11:58 AM, Luca Beltrame wrote:

...

In data lunedì 1 settembre 2014 11:45:19, Anton Aylward ha scritto:

...

Is that in time or space?

They simply have different time-based release schedules. Frameworks have a 1 month release schedule, Plasma 5 has a 3 month release schedule. They're not necessarily sequential (although work is done to prevent overlaps).

Is this illustrated (as in time-chart) somewhere rather than words-words-words? https://techbase.kde.org/Schedules/Frameworks https://techbase.kde.org/Schedules/Plasma_5 https://techbase.kde.org/Schedules/KDE4/4.14_Release_Schedule

...

...

Plasma 5 had to release past the first version of KF5 simply because, obviously, it depended on it.

Diagram of dependencies for those of us for whom all this is not "obvious", please.

I don't see how this is important to poor users... to me sounds 'important'* only for developers. What was the the point of the original mail, is to try and clarify what are upstream intentions in (close) future, and how the openSUSE KDE team plans to act according to these. In short - we'll try to make available applications based on Qt5 and KDE Frameworks 5, but we won't rush, and will use common sense in 'migrating'.

IOW, to try and making it possible that end user won't even know does he uses filemanager based on Qt4/kdelibs4 or Qt5/KF5.

Cheers, Hrvoje

* http://agateau.com/2014/dependency-diagrams-on-api.kde.org/kf5.png

Thank you very much for taking the time to supply that. As for us "POOR USERS". well it always help to understand what's under the hood. At the very least it make our reports of bugs and problem more coherent if we have some clue as to the what&where&wherefore of it all. As in: you really don't want bug reports that say "Its broken please fix it" and leave it at that. There more you can help us, the more we can help you :-) Just out of curiosity, how much is K5 drifting in the direction of being usable with Wayland without the need for Xorg? -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On 09/01/2014 02:54 PM, Luca Beltrame wrote:

...

...

#include lines, etc to new ones, Frameworks involve creativity. thought. That's cool. Applications are boooooring.

I don't see the point of sarcasm. The idea is to increase use of KDE software in the larger Qt ecosystem. I hardly think a modularization is a bad idea. Also this means that applications can have more fine-grained dependencies.

I'm sorry you see that as sarcasm. It isn't. I've been a developer and manager of development teams and a packager and also done the documentation side, and I know there's fun, creative stuff and boring tedious stuff, The latter has to be done. Sometimes you can determine patterns and automate it, sometimes not. I'm all in favour of better, more fine grained dependencies. Too much of what we have in the repositories at the moment have dependencies that are an artefact of the way things have been packaged rather than a real dependency. I'm not put out by making the zypper guts do more work :-)

...

...

BTDT. Quit a job rather than spend ho-hum days checking all the old apps worked with the new release.

KF5 is done to minimize API and ABI (binary compatibility) breakage, but it is *not guaranteed*. Just like Qt 5 is not compatible with Qt 4. So, at least by the way you wrote this, it is not possible by design.

Since that doesn't really relate to what I was thinking about when I wrote that or any permutation of my intent, I think it might help if you expanded on your explanation. You seem to be implying that at the moment there *is* breakage - whatever that is. Are you saying that, like with Qt4/5, KDE4/5 has "breakage"? Does that mean that apps we have now won't work with KF5? Which gets back to the point I was trying to make. This leads to .... migrating to 5 means the apps we used with 4 don't work until someone has done the (boring) step-and-repeat of whatever it takes to recompile or possible rewrite them to use Qt5 and run under KF5. That seems to logic to me based on what you are saying: > They need to be ported because API and ABI changed

...

...

Are they fully compatible? Has anyone - ho-hum - checked? If so, why do they need to be ported?

They need to be ported because API and ABI changed, stuff has been deprecated, etc. Also, Qt includes new things contributed by KDE, which means that some old kdelibs specific bits need to be removed. Again: Qt5 is binary incompatible with Qt4.

So, until they are all converted, (or at least the subset I use) I'm not even going to be trying. And the subset of the apps I use are not going to be the same as the next guy or the next. How are you going to prioritise this?

...

...

Sounds like its going to be confusing for a lot of people, most notably the poor end users like me.

Actually the bulk of the work stays on the shoulder of the developers (coordinating this is not trivial) and packagers (track deps, repos, etc). At least in openSUSE we'll do our best to ensure the change is transparent to the end users.

FWIW, rightly or wrongly, the KDE3/4 transition recognized that that the developers were not alone in this, that the end users played a very important part. Perhaps it was mismanaged, then, and perhaps that mismanagement is what you are trying to avoid now, but do avoid hubris. The KDE3/4 recognized the important part that end users play in the development of FOSS, their reports of use, usability, 'edge cases', and of course bugs. The handling of "activities" is a good example of that feedback. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Tuesday 02 of September 2014 01:29:28 Roman Bysh wrote:

On 09/01/2014 01:39 AM, Luca Beltrame wrote:

...

In data domenica 31 agosto 2014 19:52:34, Roman Bysh ha scritto:

...

A lot of new users do not know that KDE4 and KDE5 should not be installed and run on the same partition.

First and foremost: there is no KDE5. ;) Secondly, the wording is probably inaccurate:

- KDE Frameworks 5 (the libraries) can happily coexist with the 4.x kdelibs; - Plasma 5 (the workspace) can *not* coexist with the 4.x workspace, meaning that there is a conflict (one overwrites the other), so rather than "should not", one should say "can't" - KF5-based applications: this is a case-by-case basis. Also, no KF5 based application has had a real release yet (most are snapshots offered in KDE:Unstable:Frameworks).

IMHO zypper or the Yast Package Management should raise a flag on Plasma 5 if KDE4 is already installed.

It should _not_ allow the user to select Plasma 5 packages for installation. Installing an earlier release of Plasma 5 gave problems when trying to execute applications in KDE4. This is a bit ... confusing. Why would we provide packages if we would then want that no-one can install them?? If there are problems with the way applications are (not) working in Plasma 5 enviroment, those should be reported, not swept under the carpet.

Cheers, Hrvoje

In the end all of the problems were fixed. Hence my question.

In data lunedì 01 settembre 2014 18:58:30, Anton Aylward ha scritto:

whatever that is. Are you saying that, like with Qt4/5, KDE4/5 has "breakage"? Does that mean that apps we have now won't work with KF5? Which gets back to the point I was trying to make.

Let's tell everything from the beginning, like in the second Airplane movie. Qt moved from version 4 to version 5, back in the days, and therefore (as per their policy on major versions) they broke binary compatibility. At the same time the development process was made more open, and Qt moved to open governance. KDE thought it would be a good idea to step in to do things like: - Move very useful stuff that was inside kdelibs to Qt - Get rid of some deprecated stuff / bad decision made in the past - Generate finer-grained dependency so people would stop thinking "you need all of kdelibs for just 1 tiny class" - Improve the existing libraries Given that Qt 5 was breaking (in the sense of: you can't run a Qt 4 app against Qt 5 at runtime), they thought, and again this is OK with the project policies, to break compatibility (although only if necessary) Other KDE developers also wanted to move to Qt 5 (the Plasma developers) because it offered Qt Quick 2, which was a much better iteration of the Qt Quick 1 used in later Plasma widgets of the 4.x era. As usual, these 2 weren't compatible ;) and to make use of the new features most stuff would have to get rewritten. At the same time the basic library used by Plasma was also overhauled to remove cruft and make it into a KDE Framework. BTW: porting from Qt4 / kdelibx 4.x to Qt5 / KF5 is much easier than for KDE3 -> 4.x (which is why it took long for applications to move, back then). So what you're seeing is akin to renovation of an existing house: the foundations stay there, but a lot has changed inside.

even going to be trying. And the subset of the apps I use are not going to be the same as the next guy or the next. How are you going to prioritise this?

Depending on who gets the work done. ;)

important part. Perhaps it was mismanaged, then, and perhaps that

It was also a mismanagement on part of the distros, and openSUSE is to blame as well. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

In data lunedì 01 settembre 2014 18:58:30, Anton Aylward ha scritto:

...

whatever that is. Are you saying that, like with Qt4/5, KDE4/5 has "breakage"? Does that mean that apps we have now won't work with KF5? Which gets back to the point I was trying to make.

Let's tell everything from the beginning, like in the second Airplane movie. Qt moved from version 4 to version 5, back in the days, and therefore (as per their policy on major versions) they broke binary compatibility. At the same time the development process was made more open, and Qt moved to open governance. KDE thought it would be a good idea to step in to do things like:

- Move very useful stuff that was inside kdelibs to Qt - Get rid of some deprecated stuff / bad decision made in the past - Generate finer-grained dependency so people would stop thinking "you need all of kdelibs for just 1 tiny class" - Improve the existing libraries

Given that Qt 5 was breaking (in the sense of: you can't run a Qt 4 app against Qt 5 at runtime), they thought, and again this is OK with the project policies, to break compatibility (although only if necessary)

Other KDE developers also wanted to move to Qt 5 (the Plasma developers) because it offered Qt Quick 2, which was a much better iteration of

Quick 1 used in later Plasma widgets of the 4.x era. As usual, these 2 weren't compatible ;) and to make use of the new features most stuff would have to get rewritten. At the same time the basic library used by Plasma was also overhauled to remove cruft and make it into a KDE Framework.

BTW: porting from Qt4 / kdelibx 4.x to Qt5 / KF5 is much easier than for KDE3 -> 4.x (which is why it took long for applications to move, back then).

So what you're seeing is akin to renovation of an existing house: the foundations stay there, but a lot has changed inside.

...

even going to be trying. And the subset of the apps I use are not going to be the same as the next guy or the next. How are you going to prioritise this?

Depending on who gets the work done. ;)

...

important part. Perhaps it was mismanaged, then, and perhaps

On Tuesday, September 02, 2014 07:40:56 AM Luca Beltrame wrote: the Qt that

It was also a mismanagement on part of the distros, and openSUSE

is to blame

as well.

Thank you for taking time to explain it. -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

In data martedì 02 settembre 2014 19:49:58, Achim Gratz ha scritto:

transitions were handled in the past. Why it shouldn't be possible to separate the two at least for testing is not explained anywhere I can

Upstream has decided that libraries will be coinstallable, but workspace binaries will not, except special cases (like systemsettings). And no, we *tried* doing it differently and it was just a huge can of worms waiting to be opened. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

In data martedì 02 settembre 2014 20:17:00, Achim Gratz ha scritto:

KDE users as testers. Btw, these big-bang releases are just as big a can of worms as incremental ones. I'll watch from behind with a large bowl of popcorn, thanks.

There are other ways for testing, including live CDs. Just saying. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

On 09/02/2014 02:17 PM, Achim Gratz wrote:

Which is just another way of saying that upstream doesn't want current KDE users as testers.

Amazing! Who do they want? Gnome users? -- Hackers: Self-righteous crackers -- CSO Magazine's "The Devil's Infosec Dictionary" -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

In data mercoledì 3 settembre 2014 17:21:10, Todd Rme ha scritto:

Is there a way to install both versions of systemsettings on openSUSE? I couldn't figure out how to do it.

It is possible, but only in KDE:Unstable:SC at the moment. There is a "kdebase4-workspace-systemsettings" package which provides it (and the upstream systemsettings5 has been already adjusted for coinstallability). -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

On 09/02/2014 02:31 PM, Luca Beltrame wrote:

In data martedì 02 settembre 2014 20:17:00, Achim Gratz ha scritto:

...

KDE users as testers. Btw, these big-bang releases are just as big a can of worms as incremental ones. I'll watch from behind with a large bowl of popcorn, thanks.

There are other ways for testing, including live CDs. Just saying.

How often are those "LiveCDs" updated? Or do we have to hand-craft our own? I'd prefer to use a LiveUSB :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

On Wednesday 03 of September 2014 17:21:10 Todd Rme wrote:

On Tue, Sep 2, 2014 at 8:07 PM, Luca Beltrame wrote:

...

In data martedì 02 settembre 2014 19:49:58, Achim Gratz ha scritto:

...

transitions were handled in the past. Why it shouldn't be possible to separate the two at least for testing is not explained anywhere I can

Upstream has decided that libraries will be coinstallable, but workspace binaries will not, except special cases (like systemsettings).

And no, we *tried* doing it differently and it was just a huge can of worms waiting to be opened.

Is there a way to install both versions of systemsettings on openSUSE? I couldn't figure out how to do it.

I've made some adjustments to package in KDF, once it gets validated, it'll get in also in KDE:Current.. One note wrt systemsettings: some settings applied with Plasma 5 version, are also applied to kde4 config (e.g. style, colorscheme, menubar settings, etc) Cheers, Hrvoje

In data mercoledì 03 settembre 2014 21:07:28, Achim Gratz ha scritto:

Look, I'm using KDE daily and I don't look forward to yet another week

So do I, so do others on this list as well, including the other KDE team members.

w.r.t. kmail. Developers actively burning the bridges that would allow going back at least temporarily is never a good sign, whatever the

"Actively burning bridges" is an overstatement, IMO. It's a major transition and things will need time to settle. It's being handled quite well so far, IMO.

that's not going to happen often enough or exercising the new stuff deeply enough for the testing to be of any use.

Understandable: still, the option will be there for whoever wants to. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/02/2014 01:40 AM, Luca Beltrame wrote:

In data lunedì 01 settembre 2014 18:58:30, Anton Aylward ha scritto:

...

whatever that is. Are you saying that, like with Qt4/5, KDE4/5 has "breakage"? Does that mean that apps we have now won't work with KF5? Which gets back to the point I was trying to make.

Let's tell everything from the beginning, like in the second Airplane movie. Qt moved from version 4 to version 5, back in the days, and therefore (as per their policy on major versions) they broke binary compatibility. At the same time the development process was made more open, and Qt moved to open governance. KDE thought it would be a good idea to step in to do things like:

- Move very useful stuff that was inside kdelibs to Qt - Get rid of some deprecated stuff / bad decision made in the past - Generate finer-grained dependency so people would stop thinking "you need all of kdelibs for just 1 tiny class" - Improve the existing libraries

Given that Qt 5 was breaking (in the sense of: you can't run a Qt 4 app against Qt 5 at runtime), they thought, and again this is OK with the project policies, to break compatibility (although only if necessary)

Other KDE developers also wanted to move to Qt 5 (the Plasma developers) because it offered Qt Quick 2, which was a much better iteration of the Qt Quick 1 used in later Plasma widgets of the 4.x era. As usual, these 2 weren't compatible ;) and to make use of the new features most stuff would have to get rewritten. At the same time the basic library used by Plasma was also overhauled to remove cruft and make it into a KDE Framework.

BTW: porting from Qt4 / kdelibx 4.x to Qt5 / KF5 is much easier than for KDE3 -> 4.x (which is why it took long for applications to move, back then).

So what you're seeing is akin to renovation of an existing house: the foundations stay there, but a lot has changed inside.

...

even going to be trying. And the subset of the apps I use are not going to be the same as the next guy or the next. How are you going to prioritise this?

Depending on who gets the work done. ;)

...

important part. Perhaps it was mismanaged, then, and perhaps that

It was also a mismanagement on part of the distros, and openSUSE is to blame as well.

I'd like to thank you all especially Luca for a very informative discussion. All of my questions have been answered.;-) Cheers! Roman -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJUB4SrAAoJEISyH9AowGDQmgEH/R0rhvYci1kXRu8SyaMHs8dl 1EhXxbG8/FMaYw2zaeLKaHDfbrrKmHuD1X4hscVsIEKc05zTqT2zp4UGUUDyUj+7 uU6jBllm+gMXQDnY+2y9PQUQzSrMNj0QcCMISST9vY2HARlfGgmXFmg8FyeNl3Rw ffulY3i++Q+TAIe4Qjz2vPriyp+xKmC2T3L+9I26ggMbYN79YaET19HmfUEPnr/o 06ETcF3pKNhZTeLFGo+VsmAU4T8BMiIPGEqjWlD+Ke3zx5+FwMgivOANESyiu5zU QYBYcGZxhdGJtdZR2KX5crlCF7RiXYjEPnDFoC329dNx2aR7i3XYaaHj6GWCjio= =dAMU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Am Montag, 1. September 2014, 07:39:16 schrieb Luca Beltrame:

- KDE Frameworks 5 (the libraries) can happily coexist with the 4.x kdelibs; - Plasma 5 (the workspace) can *not* coexist with the 4.x workspace, meaning that there is a conflict (one overwrites the other), so rather than "should not", one should say "can't" - KF5-based applications: this is a case-by-case basis. Also, no KF5 based application has had a real release yet (most are snapshots offered in KDE:Unstable:Frameworks).

Hi all! Sorry for joining in late. For anybody that's interested in trying out Plasma 5 on their existing openSUSE system without removing KDE4, I do maintain a repo on OBS that contains versions of the Plasma 5 packages that can be co-installed with KDE4. See https://forums.opensuse.org/showthread.php/499607-KDE5?p=2654365#post2654365 In short: Add my repo in addition to the "official" 2 repos. For 13.1 that is http://download.opensuse.org/repositories/home:/wolfi323:/branches:/KDE:/Fra... or for Factory http://download.opensuse.org/repositories/home:/wolfi323:/branches:/KDE:/Fra... (you might want to give my repo a higher priority to be sure it gets preferred). Then install plasma5-session from my repo. This should add a "Plasma 5" entry to your login screen, and pull in all packages that are needed to use Plasma 5. With my packages you can also keep using KDM as display/login manager, as it doesn't have to be uninstalled... ;) I only keep packages that conflict with KDE4 in there, so it is absolutely necessary to have the other two repos as well. And I try to keep them as up-to-date as possible. (normally this should happen automatically, but sometimes there are conflicts I have to solve...) As a bonus, I also added KF5 versions of selected KDE applications there, again they can be co-installed with their KDE4 versions. E.g.: kate/kwrite, konsole, gwenview, dolphin, k3b, ... Use YaST's View->Repositories to see what's available. But please note, that those are only development snapshots from KDE:Unstable:Frameworks, that haven't been released yet. In my experience most of them work reliably, but there might be problems. (dolphin e.g. doesn't save the window size properly), although I haven't used _all_ of them extensively yet. I plan to switch them to the versions from KDE:Frameworks5, as soon they are available there. The intention of this repo is to be as stable as possible. (I might do something similar for KDE:Unstable:Frameworks in the future though, if there's demand for it) My packages should not influence the existing KDE4 installation whatsoever. But as has been mentioned in this thread already, Plasma 5 does do some changes (like fonts, widget style, color scheme, ...) to the KDE4 settings, so you might want to create a new user anyway for trying it. This is done on purpose (by upstream) to make KDE4 applications integrate better into a Plasma 5 desktop. If you have question, feel free to ask here, or in that forum thread I mentioned. ;) Kind Regards, Wolfgang PS: My thanks go to the openSUSE KDE team for making this possible. :-) They did/do most of the work, not me. I only branched the existing packages on OBS and change them if necessary to avoid conflicts... -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Am Dienstag, 9. September 2014, 17:02:42 schrieb Alfonso Castro:

I installed the packages and it didn't work.

In first time, I had to edit plasma5.desktop to use /opt/kf5/bin/startkde, not /usr/bin/startkde.

Then, it gives an error with kdeinit, it search some libraries in /usr/lib64/ when there are in /opt/kf5/lib64.

Then you didn't install the packages from my repo, but from KDE:Frameworks5, in particular plasma5-session. My plasma.desktop definitely calls /opt/kf5/bin/startkde, and sets the appropriate search paths to prefer /opt/kf5/... Try to use YaST's View->Repositories and its "Versions" tab (below the package list) to make sure all packages (as I said, plasma5-session in particular, but also plasma5-workspace and -desktop) come from my repo. Kind regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Am Montag, 1. September 2014, 07:39:16 schrieb Luca Beltrame:

...

- KDE Frameworks 5 (the libraries) can happily coexist with the 4.x kdelibs; - Plasma 5 (the workspace) can *not* coexist with the 4.x workspace, meaning that there is a conflict (one overwrites the other), so rather than "should not", one should say "can't" - KF5-based applications: this is a case-by-case basis. Also, no KF5 based application has had a real release yet (most are snapshots offered in KDE:Unstable:Frameworks).

Hi all! Sorry for joining in late.

For anybody that's interested in trying out Plasma 5 on their existing openSUSE system without removing KDE4, I do maintain a repo on OBS that contains versions of the Plasma 5 packages that can be co-installed with KDE4.

See https://forums.opensuse.org/showthread.php/499607-KDE5?p=2654365#post26543 65

In short: Add my repo in addition to the "official" 2 repos. For 13.1 that is http://download.opensuse.org/repositories/home:/wolfi323:/branches:/KDE:/F rameworks5/openSUSE_13.1/ or for Factory http://download.opensuse.org/repositories/home:/wolfi323:/branches:/KDE:/F rameworks5/openSUSE_Factory (you might want to give my repo a higher priority to be sure it gets preferred).

Then install plasma5-session from my repo. This should add a "Plasma 5" entry to your login screen, and pull in all packages that are needed to use Plasma 5. With my packages you can also keep using KDM as display/login manager, as it doesn't have to be uninstalled... ;)

I only keep packages that conflict with KDE4 in there, so it is absolutely necessary to have the other two repos as well. And I try to keep them as up-to-date as possible. (normally this should happen automatically, but sometimes there are conflicts I have to solve...)

As a bonus, I also added KF5 versions of selected KDE applications there, again they can be co-installed with their KDE4 versions. E.g.: kate/kwrite, konsole, gwenview, dolphin, k3b, ... Use YaST's View->Repositories to see what's available.

But please note, that those are only development snapshots from KDE:Unstable:Frameworks, that haven't been released yet. In my experience most of them work reliably, but there might be problems. (dolphin e.g. doesn't save the window size properly), although I haven't used _all_ of them extensively yet. This was actually a combo of bugs, one Qt, other KXmlGui - for first we have

On Tuesday 09 of September 2014 13:03:38 Wolfgang Bauer wrote: the patch in KDE:Qt5 and Factory soon, and KXmlGui one is fixed with 5.2.0 release =) Cheers, Hrvoje

I plan to switch them to the versions from KDE:Frameworks5, as soon they are available there. The intention of this repo is to be as stable as possible. (I might do something similar for KDE:Unstable:Frameworks in the future though, if there's demand for it)

My packages should not influence the existing KDE4 installation whatsoever. But as has been mentioned in this thread already, Plasma 5 does do some changes (like fonts, widget style, color scheme, ...) to the KDE4 settings, so you might want to create a new user anyway for trying it. This is done on purpose (by upstream) to make KDE4 applications integrate better into a Plasma 5 desktop.

If you have question, feel free to ask here, or in that forum thread I mentioned. ;)

Kind Regards, Wolfgang

PS: My thanks go to the openSUSE KDE team for making this possible. :-) They did/do most of the work, not me. I only branched the existing packages on OBS and change them if necessary to avoid conflicts...

Am Dienstag, 9. September 2014, 20:01:16 schrieb šumski:

On Tuesday 09 of September 2014 13:03:38 Wolfgang Bauer wrote:

...

But please note, that those are only development snapshots from KDE:Unstable:Frameworks, that haven't been released yet. In my experience most of them work reliably, but there might be problems. (dolphin e.g. doesn't save the window size properly), although I haven't used _all_ of them extensively yet.

This was actually a combo of bugs, one Qt, other KXmlGui - for first we have the patch in KDE:Qt5 and Factory soon, and KXmlGui one is fixed with 5.2.0 release =)

You mean the problem with dolphin I mentioned? Good to hear! At the moment it fails to build anyway, as it needs things from Frameworks 5.2 (as you probably know yourself I suppose... ;) ). So this particular problem should be fixed on Thursday then, I guess... Kind regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org

Am Mittwoch, 10. September 2014, 12:06:58 schrieb Alfonso Castro:

It was to be sure. I think it is the composer, sometimes plasma 5 crash. In this computer the graphics card is Nvidia, in the other Intel. Also, I'll review the config,

Well, I do not provide kwin in my repo, you are in fact using kwin5 from KDE:Frameworks5. (kwin5 does not conflict with KDE4; the executable has been renamed upstream to kwin_x11, as there will be a kwin_wayland as well...) So if the compositor has a problem, it is definitely not related to my packages. That said, I did experience some Plasma crashes from time to time myself, mainly when browsing the K-menu. I haven't investigated further yet, but the crashes seemed to be inside QtQuick IIRC, so that shouldn't be a problem with my packages either... Just to clarify: I do not make any changes to the packages, unless necessary to install them to /opt/kf5. In particular the used source code and additional patches are the same as in KDE:Frameworks5 Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org