[opensuse-kde] KDE 4.14.0 in KDE:Current and a look to the future
HI openSUSE KDE user. At this moment the KDE:Current repository is almost finished building the latest KDE SC 4.14.0 release and the expectation is that the repositories will be published very soon. It could take still some time before the KDE:Extra repository catches up. With a look to the future, KDE Upstream has decided that 4.14 will be the last KDE 4 Applications release and that after that they would switch (at least for a while) to application releases where applications are either kdelibs4 based or KF5 based. The naming for these Application releases would be KDE Applications $YEAR.$MONTH and the next one planned would be KDE Applications 14.12 and it is unknown which applications will be switching to KF5 for that particular release. For KDE:Current users, this would mean that the repository will remain kdelibs4 based and that we will just update those applications that are still kdelibs4 based. Other packages will remain on their respective latest versions. In practice this will also mean that packages will deviate in their version number (similar to what is already the situation with kdebase4-workspace). What the situation will be for KDE:Distro:Factory and openSUSE:Factory itself is not yet clear, but I would imagine that we would still remain with a default kdelibs4 based desktop and trying to ship as many kf5 applications as possible for those that want to switch. The version shipped in KDE:Current will be revisited as soon as all KDE applications are KF5 based. In all honesty I would like to avoid a setup where we would have a KDE3, KDE4 and KF5 repository. Regards Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/31/2014 03:22 PM, Raymond Wooninck wrote:
HI openSUSE KDE user.
At this moment the KDE:Current repository is almost finished building the latest KDE SC 4.14.0 release and the expectation is that the repositories will be published very soon. It could take still some time before the KDE:Extra repository catches up.
With a look to the future, KDE Upstream has decided that 4.14 will be the last KDE 4 Applications release and that after that they would switch (at least for a while) to application releases where applications are either kdelibs4 based or KF5 based.
The naming for these Application releases would be KDE Applications $YEAR.$MONTH and the next one planned would be KDE Applications 14.12 and it is unknown which applications will be switching to KF5 for that particular release.
For KDE:Current users, this would mean that the repository will remain kdelibs4 based and that we will just update those applications that are still kdelibs4 based. Other packages will remain on their respective latest versions. In practice this will also mean that packages will deviate in their version number (similar to what is already the situation with kdebase4-workspace).
What the situation will be for KDE:Distro:Factory and openSUSE:Factory itself is not yet clear, but I would imagine that we would still remain with a default kdelibs4 based desktop and trying to ship as many kf5 applications as possible for those that want to switch.
The version shipped in KDE:Current will be revisited as soon as all KDE applications are KF5 based. In all honesty I would like to avoid a setup where we would have a KDE3, KDE4 and KF5 repository.
Regards
Raymond A lot of new users do not know that KDE4 and KDE5 should not be installed and run on the same partition.
i.e. running KDE4 series and then running KDE5 or Plasma Next. - -- Cheers! Roman - -------------------------------------------- openSUSE -- Get it! Discover it! Share it! - -------------------------------------------- http://linuxcounter.net/ #179293 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJUA7VCAAoJEISyH9AowGDQbiIH/Rrx5VrOdTnyQOgluruoYGmy 5ZBLxPwXYxp8BmWrp+QCYRDPA01ShaYkeftOeKDrtjqKrhh0zxCoBh7Px9ftKZfo x6H0HBxlqt9H2WgKipmBtc54gTWDq0zEe9uK63gk/4rAIWkMJhDU4/2ns4vJXkb/ d9OS/+miw+Skn8zBEGiOMGge39anCEVHu6qmQ03iCuTvnZ+iPaC8p8MaFCzbydtT OM4ISPAYslCn59eMlJxFJ/KLOGD6Cu6UB+jNnGiG2LGHgl3QhSClSHX24pzaVB5b 7SXTuHi/48upm8bvsRzEnhjvS0cMuKSusyxdPGH8CjDO6ToZIm0uhU7ea52YCOA= =uxiP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. In the end all of the problems were fixed. Hence my question. - -- Cheers! Roman -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJUBQFYAAoJEISyH9AowGDQ180IAI4tio1H3rAbU1A4iF9gWvLO WA3YMFNJnxATwVWED4UTVFheBphjClWGb5+9V6MTIiciPJUcfmeaXD42V5YC7iJ6 Ei+m+lXprC9EDa69WKE82GPrhWOwqp1hUltGxEaqWfyLu1JQ188Tk8y1rNEAMJf9 qM17Ppp68sSns7C54f4zYr1kAUdJtOo6FZoz4rz24rm8QO5W3LmVSbbgcck8x/MV KfbT62dDUXWQ7moDjGwwff1yzZkvRLZz1tn6tDAk8+dPD8nu9poK10TABeQPD49L n0OI8CP94g5x1L7pFKyF4u/sXxQ9d0A+DpvFmAQs6TQgKeaZxwyFMJKreUgZI+k= =bJjd -----END PGP SIGNATURE----- -- 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 19:29:28, Roman Bysh ha scritto:
IMHO zypper or the Yast Package Management should raise a flag on Plasma 5 if KDE4 is already installed. Installing an earlier release of Plasma 5 gave problems when trying to execute applications in KDE4.
Sorry, but this makes no sense. The problem you highlighted was a *packaging* problem, and we realized later only because Raymond and shumski weren't using some applications (KDevelop) I was dependent on. When I tried using them things broke, and we fixed the packages (and some bits upstream). This is part of the regular testing we do. Preventing choice (which won't be a default, as we stated seeral times) will not get any testing done. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
Luca Beltrame writes:
- 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"
That's shocking, but not etirely unexpected given how similar 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 find easily. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- 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
Luca Beltrame writes:
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.
Which is just another way of saying that upstream doesn't want current 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. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra -- 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 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: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 2014-09-03 12:23 (GMT-0400) Anton Aylward composed:
Luca Beltrame wrote:
There are other ways for testing, including live CDs. Just saying.
I'd prefer to use a LiveUSB :-)
I prefer not downloading pre-release software isos of any kind, so as besides not downloading stuff never to be used (libreoffice, kmail, kontact, kopete, wireless*, providers, etc), also not to be tripping over default settings to find out if things work the way I want and/or like. My test installs typically take up somewhere around 3GB, done minimal initially, adding more only after setting solver.onlyRequires = true that I've never found any way to set at install time. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
In data mercoledì 03 settembre 2014 12:23:08, Anton Aylward ha scritto:
How often are those "LiveCDs" updated? Or do we have to hand-craft our own?
Unlike Kubuntu's, whenever there's free time for it. In fact help is welcome to make things more periodic. ;) -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
Luca Beltrame writes:
There are other ways for testing, including live CDs. Just saying.
Look, I'm using KDE daily and I don't look forward to yet another week of frantically trying to get my desktop working again, barely; then waiting for another two years for the rest of it, and ultimately in vain w.r.t. kmail. Developers actively burning the bridges that would allow going back at least temporarily is never a good sign, whatever the intentions. If I can't test Plasma5 on the same machine and preferrably chose the desktop version depending on how experimental I can be today, then that's not going to happen often enough or exercising the new stuff deeply enough for the testing to be of any use. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
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
On Wed, 3 Sep 2014 21:07:28 Achim Gratz wrote:
Luca Beltrame writes:
There are other ways for testing, including live CDs. Just saying.
Look, I'm using KDE daily and I don't look forward to yet another week of frantically trying to get my desktop working again, barely; then waiting for another two years for the rest of it, and ultimately in vain w.r.t. kmail. Developers actively burning the bridges that would allow going back at least temporarily is never a good sign, whatever the intentions.
If I can't test Plasma5 on the same machine and preferrably chose the desktop version depending on how experimental I can be today, then that's not going to happen often enough or exercising the new stuff deeply enough for the testing to be of any use.
Then there is always xen/virtualbox/vmware/other vm solution. The beauty of that is that one can install the beta in a virtual machine, play with it, test it (albeit not on "real" video hardware), blow it away and start again, all the while keeping your main desktop intact, in most cases without ever having to reboot your host machine (if you don't want to). -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
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 11:43:20, Anton Aylward ha scritto:
Who do they want? Gnome users?
I would suggest you to re-read the thread before making unfounded statements about upstream. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
On 09/03/2014 11:46 AM, Luca Beltrame wrote:
In data mercoledì 3 settembre 2014 11:43:20, Anton Aylward ha scritto:
Who do they want? Gnome users?
I would suggest you to re-read the thread before making unfounded statements about upstream.
In case you hadn't noticed, I've been active on this thread and paying attention. If you've followed the main thread or the 3/4 transition you'll know that I'm a fervent supporter of KDE, defending 4 against the naysayers of that time. I'll leave the issue of whether Gnome is a joke to your imaginations. What I paid attention here was an wonderfully ambiguous and to my mind highly amusing wording. It you guys can't take a bit of fun then your skins are too thin to be in this business. -- /"\ \ / 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 Tue, Sep 2, 2014 at 8:07 PM, Luca Beltrame
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. -- 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 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
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
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. I used a new user. Best regards. Alfonso O Martes, 9 de Setembro de 2014 13:03:38 Wolfgang Bauer escribiu:
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#post265436 5
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:/Fr ameworks5/openSUSE_13.1/ or for Factory http://download.opensuse.org/repositories/home:/wolfi323:/branches:/KDE:/Fr ameworks5/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.
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
You have reason, Yast installed plasma5-session from KDF5. I made a test and it is less stable that the install I have in another computer only with packages from KF5. Is this normal or it is so stable like KDF5? Thanks. Alfonso O Martes, 9 de Setembro de 2014 18:15:14 Wolfgang Bauer escribiu:
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 Dienstag, 9. September 2014, 19:42:27 schrieb Alfonso Castro:
You have reason, Yast installed plasma5-session from KDF5.
Right. Just to be clear, because I mentioned "you might want to give my repo a higher priority to be sure it gets preferred": Higher priority means _lower_ number... ;)
I made a test and it is less stable that the install I have in another computer only with packages from KF5.
Is this normal or it is so stable like KDF5?
Could you clarify a bit, please? What exactly do you mean with "less stable"? I'm not aware of any stability problems, it runs fine here, on two different systems. It _should_ be as stable as KDE:Frameworks5 anyway, as it's the same actually. But I did have to patch some things so that it works fine in /opt/kf5/ with KDE4 along (in particular some KAuth helpers to get root permissions, namely in powerdevil and ksysguard...). Kind regards, Wolfgang -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
O Martes, 9 de Setembro de 2014 20:34:17 Wolfgang Bauer escribiu:
Am Dienstag, 9. September 2014, 19:42:27 schrieb Alfonso Castro:
You have reason, Yast installed plasma5-session from KDF5.
Right. Just to be clear, because I mentioned "you might want to give my repo a higher priority to be sure it gets preferred": Higher priority means _lower_ number... ;)
I made two errors.
I made a test and it is less stable that the install I have in another computer only with packages from KF5.
Is this normal or it is so stable like KDF5?
Could you clarify a bit, please?
What exactly do you mean with "less stable"? I'm not aware of any stability problems, it runs fine here, on two different systems.
It _should_ be as stable as KDE:Frameworks5 anyway, as it's the same actually.
But I did have to patch some things so that it works fine in /opt/kf5/ with KDE4 along (in particular some KAuth helpers to get root permissions, namely in powerdevil and ksysguard...).
Kind regards, Wolfgang
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, Best regards. Alfonso -- 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
My same experience, the crashes are with K menu. I changed to homerun syle menu and the crashes stop, by the moment. Best regards. Alfonso O Mércores, 10 de Setembro de 2014 15:40:51 Wolfgang Bauer escribiu:
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
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
Thanks for the update. I was hoping KDE4 and Apps would keep being
maintained for another year or two in a maintenance mode while Plasma
5 is maturing and Apps are being ported to avoid a major user backlash
like what happened with KDE4 when it started shipping too early in the
mainline distros.
On Sun, Aug 31, 2014 at 2:22 PM, Raymond Wooninck
HI openSUSE KDE user.
At this moment the KDE:Current repository is almost finished building the latest KDE SC 4.14.0 release and the expectation is that the repositories will be published very soon. It could take still some time before the KDE:Extra repository catches up.
With a look to the future, KDE Upstream has decided that 4.14 will be the last KDE 4 Applications release and that after that they would switch (at least for a while) to application releases where applications are either kdelibs4 based or KF5 based.
The naming for these Application releases would be KDE Applications $YEAR.$MONTH and the next one planned would be KDE Applications 14.12 and it is unknown which applications will be switching to KF5 for that particular release.
For KDE:Current users, this would mean that the repository will remain kdelibs4 based and that we will just update those applications that are still kdelibs4 based. Other packages will remain on their respective latest versions. In practice this will also mean that packages will deviate in their version number (similar to what is already the situation with kdebase4-workspace).
What the situation will be for KDE:Distro:Factory and openSUSE:Factory itself is not yet clear, but I would imagine that we would still remain with a default kdelibs4 based desktop and trying to ship as many kf5 applications as possible for those that want to switch.
The version shipped in KDE:Current will be revisited as soon as all KDE applications are KF5 based. In all honesty I would like to avoid a setup where we would have a KDE3, KDE4 and KF5 repository.
Regards
Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
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 Monday 01 September 2014 15:43, Timothy Butterworth wrote:
Thanks for the update. I was hoping KDE4 and Apps would keep being maintained for another year or two in a maintenance mode while Plasma 5 is maturing and Apps are being ported to avoid a major user backlash like what happened with KDE4 when it started shipping too early in the mainline distros.
As Luca already indicated, some components of KDE4 are in a long-term support mode. Especially the workspace which is already in this mode since KDE 4.11 release. However we should remember that KF5 is different in its releases than KDE4. KF5 will have three independent releases (Framework, Plasma and Applications). 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. But as indicated for the upcoming 13.2 we will ship it with KDE4 as default and we will ship alongside it the Frameworks 5 and Plasma 5 packages. Unfortunately it is not possible to have both kdebase4-workspace and Plasma 5 installed. For next year, we might consider moving components to KF5 (e.g.replacing Workspace (4.x) with Plasma 5), while keeping non-mature Applications on their respective KDE4 versions. But this is all speculation and we will start drafting plans end of this year after the release of KDE Applications 14.12. And even then we will only make changes to KDE:Distro:Factory and openSUSE:Factory. KDE:Current will remain at least until the last KDE4 application has been ported or made obsolete within KF5). Raymond -- To unsubscribe, e-mail: opensuse-kde+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kde+owner@opensuse.org
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
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). Plasma 5 had to release past the first version of KF5 simply because, obviously, it depended on it.
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.
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.
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). 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. -- Luca Beltrame - KDE Forums team KDE Science supporter GPG key ID: 6E1A4E79
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
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
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 Monday 01 of September 2014 22:32:24 Anton Aylward wrote:
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? Slooowly moving there, but lots of work to be done.
Cheers, Hrvoje
Hi All, Now I got it. As an end user, I need not bother about KF5/Plasma5/KApps5. All I need is latest/greatest of KDE Applications, which I am dependent on for everyday usage. Whether an KApp will run on particular version of Plasma5 or which version of KF5 should such KApp will be taken care by developers. Excellent! Now, as a curious user (longing to use KApp5 earliest - snapshots in web are lovely/intriguing), I would wait for openSUSE to release them in a repository (not necessarily KDE:Current) so that we can quench the thirst! Thanks for everyone, who boldly asked questions (in our users' heart) and developers who patiently answered them. Regards and wishes, Rajesh šumski wrote:
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'.
-- 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 Monday 01 September 2014 20.54:13 Luca Beltrame wrote:
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.
And for that guys, you really deserve our recognition. I especially appreciate the way you initiate the communication, and expose your plan as kde packager team for openSUSE. I encourage any "end-users" reading on the list, to do their best for helping all of us already contributing, by for example, trying to figure out this new galaxy is drawn, and propose a à la noobs content for the wiki with nice diagrams. There's no good reason to not jump on the contributing side ;-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch ------------------------ / openSUSE Member & Board \ / GPG KEY : D5C9B751C4653227 \ \ irc: tigerfoot / ------------------------ \ /@ --~-. \/ __ .- | // // @
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
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
-----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
participants (16)
-
Achim Gratz
-
Alfonso Castro
-
Alfonso Castro
-
Anton Aylward
-
Bruno Friedmann
-
CA G Rajesh
-
Felix Miata
-
Luca Beltrame
-
Raymond Wooninck
-
Rick Chung
-
Rodney Baker
-
Roman Bysh
-
Timothy Butterworth
-
Todd Rme
-
Wolfgang Bauer
-
šumski