-----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

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

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 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

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

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

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 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. -- 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

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

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

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

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 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

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

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

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

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 / ------------------------ \ /@ --~-. \/ __ .- | // // @

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

-----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