Re: [kde-community] QtCurve
On Monday 20 January 2014 23:44:01 Eike Hein wrote: > On Monday 20 January 2014 17:13:47 Yichao Yu wrote: > > QtCurve (although being not very polished) is already stable and have > > made several releases that are packaged by a number of distributions. > > Is there anything I am missing here? > > I think Kevin just wanted to point out there's an additional > wiki page we can link now :) That *and* the incubator is also meant for projects having a "not yet part of KDE" team joining. For instance if VLC would ever want to join (random example) it would go through the incubator still, even though it is "is already stable and have made several releases that are packaged by a number of distributions". The purpose of the incubator is not just technical but also to make sure projects are well alive, active and integrated in the community. Now, does it apply to QtCurve? At a glance I thought it did, I can't really say for sure and could be totally wrong. :-) Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] QtCurve
On Monday 20 January 2014 17:13:47 Yichao Yu wrote: > QtCurve (although being not very polished) is already stable and have > made several releases that are packaged by a number of distributions. > Is there anything I am missing here? I think Kevin just wanted to point out there's an additional wiki page we can link now :) I think this thread and the steps that have been discussed basically meet what's outlined there, so it's all good. It comes down to the Manifesto and the kdereview-en-route- to-Extragear thing, and since the former's already been covered and QtCurve is a well-established codebase that's working for real people for a long time already I don't think there's likely to be significant problems. BTW: Super-happy to hear about this, welcome! > Yichao Yu Cheers, Eike ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] QtCurve
On Mon, Jan 20, 2014 at 10:12 AM, Kevin Ottens wrote: > Hello, > > Note there's the incubator now for existing projects willing to join: > http://community.kde.org/Incubator > I have seen the email of the restarted Incubator project before but I thought it was mainly for start up projects? QtCurve (although being not very polished) is already stable and have made several releases that are packaged by a number of distributions. Is there anything I am missing here? Yichao Yu ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] QtCurve
On Mon, Jan 20, 2014 at 12:32 PM, Martin Sandsmark wrote: > On Mon, Jan 20, 2014 at 08:53:34AM -0500, Yichao Yu wrote: >> I would like to move QtCurve to the KDE infrastructure > > Yes! :-D > > I've been using QtCurve for a while now, and I'd even argue for replacing > Oxygen with it for KDE Plasma Desktop Framework Visual Team Studio 5 SC > Edition 2014.1, with the right default configuration it would be a refreshing > new default style. But I don't have the argument stamina for that. :-P I'm glad you like it and thank you for you support ;). However, I don't really think it is a good idea to replace the default theme right now both because it is not as polished as oxygen (which is what I'm mainly working on) and because it has similar blacklist problem with oxygen-transparent (because it also provide transparent background support, which is actually an advantage of not being the default theme). I do think that it will be helpful to make it an alternative to the oxygen theme and that's also why I am sending the email. Yichao Yu P.S. at the same time, your email remind me a point that I was missing. AFAIK, QtCurve is the first and only 3rd party Qt5 theme that has been packaged by distribution (ArchLinux). This should be useful before Oxygen-Qt5/KF5 is released :-P. > > -- > Martin Sandsmark > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
I first wrote a long reply talking crap about UX and regressions, but I re-read it and thought about kittens instead, so I deleted it. On Mon, Jan 20, 2014 at 07:05:24PM +0100, Aaron J. Seigo wrote: > Agreed, or at the very least has parity. This is all I really want. Don't remove kcalc until the replacement has parity. And thank you for working on this. :-) -- Martin Sandsmark ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
On Mon, Jan 20, 2014 at 06:42:14PM +0100, Martin Klapetek wrote: > Just for the record, we now have almost 1-to-1 visual consistency of > QtQuickControls with Oxygen style and classic QWidgets with Oxygen style. > Couple patches are still pending. I think the amount of work that has gone into Oxygen for this speaks for itself, though. > The QStyle support in QQC may be a bit hack~ish, but I wouldn't say exactly > poor - in fact, all the default Qt styles work fine with QQC (that includes > Windows and OS X QStyles). Obviously, otherwise QQC could hardly have been released. :-) But not everyone use the default styles that ship with Qt5. Hopefully this will improve, though I'm not very hopeful since people just hack around stuff in the styles themselves. -- Martin Sandsmark ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
On Monday, 2014-01-20, 18:29:16, Martin Sandsmark wrote: > The current kcalc UI is very good, I often use it for stuff like bit > fiddling, etc. I can't say the same thing for the calculator plasma applet. > But please feel free to prove me wrong and make the plasma calculator much > better than kcalc. But I'd argue very strongly to not replace kcalc until > the replacement is visibly better. > > The obvious downsides things being replaced would suffer from, thanks to the > immature state of the desktop components, and not including the previously > mentioned obviously broken components; dreadful performance, no proper > accelerator management, no form layouts, and poor QStyle support (both > Oxygen and QtCurve has worked around some of them now, though, but I doubt > it will be good for a long, long while). QtQuick.Controls is just one possible option for using a QML compatible application core. If a QtWidget UI is better for whatever use case then this is doable by just importing a QtWidget based component set and making sure that whatever loads the QML has an QApplication instantiated (insteead of just a QGuiApplication). A Plasma applet, a QtQuick.Controls applications and a QtWidgets application can use application classes. Even use them identically if the application classes are in a QML plugin and the object instantiation is done by a QML engine. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
On Monday, January 20, 2014 18:29:16 Martin Sandsmark wrote: > On Mon, Jan 20, 2014 at 11:10:06AM +0100, Aaron J. Seigo wrote: > > namely duplication of effort and inconsistency due to multiple > > implementations of what is from a use case perspective the same thing. > > This would be all well and good if it wasn't for the gross regressions it > would suffer. Yes, you don’t have to believe me. > You argued the exact same thing for the screen locker. Er, no, actually. That was a completely different decision matrix that bears zero resemblance to this one. The screen locker was about consistency with other desktop shell components, the application issue is about deduplication of effort. > But what you're > arguing is a kind of false dichtomy. You would think that instead of two > half-assed solutions we would get a single superior implementation, but > instead we get a single inferior one. I disagree; ultimately the code will decide who was right, though with stop energy like this I can imagine the experiment never being undertaken at all. > > For things like kcalc, the things the desktop components are not good at > > are irrelevant; the things it *is* good at could radically improve its > > UI. > The thing I'm unable to discern is how it would radically improve its UI. For one: by having a nice paper-tape presentation of the calculation with history. Rather easier to do in a visually pleasant way with QML. > The current kcalc UI is very good, I often use it for stuff like bit > fiddling, etc. I can't say the same thing for the calculator plasma applet. > But please feel free to prove me wrong and make the plasma calculator much > better than kcalc. I would expect a QML UI on top of the kcalc logic would be a far more sensible approach. Not sure why you would think we’d go at it from the other direction. > But I'd argue very strongly to not replace kcalc until > the replacement is visibly better. Agreed, or at the very least has parity. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
On Mon, Jan 20, 2014 at 6:29 PM, Martin Sandsmark wrote: > > The obvious downsides things being replaced would suffer from, thanks to > the > immature state of the desktop components, and not including the previously > mentioned obviously broken components; dreadful performance, no proper > accelerator management, no form layouts, and poor QStyle support (both > Oxygen > and QtCurve has worked around some of them now, though, but I doubt it will > be good for a long, long while). > Just for the record, we now have almost 1-to-1 visual consistency of QtQuickControls with Oxygen style and classic QWidgets with Oxygen style. Couple patches are still pending. The QStyle support in QQC may be a bit hack~ish, but I wouldn't say exactly poor - in fact, all the default Qt styles work fine with QQC (that includes Windows and OS X QStyles). Cheers -- Martin Klapetek | KDE Developer ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] QtCurve
On Mon, Jan 20, 2014 at 08:53:34AM -0500, Yichao Yu wrote: > I would like to move QtCurve to the KDE infrastructure Yes! :-D I've been using QtCurve for a while now, and I'd even argue for replacing Oxygen with it for KDE Plasma Desktop Framework Visual Team Studio 5 SC Edition 2014.1, with the right default configuration it would be a refreshing new default style. But I don't have the argument stamina for that. :-P -- Martin Sandsmark ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
On Mon, Jan 20, 2014 at 11:10:06AM +0100, Aaron J. Seigo wrote: > namely duplication of effort and inconsistency due to multiple > implementations of what is from a use case perspective the same thing. This would be all well and good if it wasn't for the gross regressions it would suffer. You argued the exact same thing for the screen locker. But what you're arguing is a kind of false dichtomy. You would think that instead of two half-assed solutions we would get a single superior implementation, but instead we get a single inferior one. > For things like kcalc, the things the desktop components are not good at are > irrelevant; the things it *is* good at could radically improve its UI. The thing I'm unable to discern is how it would radically improve its UI. The current kcalc UI is very good, I often use it for stuff like bit fiddling, etc. I can't say the same thing for the calculator plasma applet. But please feel free to prove me wrong and make the plasma calculator much better than kcalc. But I'd argue very strongly to not replace kcalc until the replacement is visibly better. The obvious downsides things being replaced would suffer from, thanks to the immature state of the desktop components, and not including the previously mentioned obviously broken components; dreadful performance, no proper accelerator management, no form layouts, and poor QStyle support (both Oxygen and QtCurve has worked around some of them now, though, but I doubt it will be good for a long, long while). And I'm not alone in believing this (others have used the desktop components more than me), but I don't want to drag others into this discussion. -- Maritn Sandsmark ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] QtCurve
Hello, On Monday 20 January 2014 15:29:00 David Edmundson wrote: > Brilliant. > > So the next page to read is > http://techbase.kde.org/Policies/Application_Lifecycle. It explains > the entrance process and the SC vs extragear. Note there's the incubator now for existing projects willing to join: http://community.kde.org/Incubator Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] QtCurve
On Mon, Jan 20, 2014 at 9:29 AM, David Edmundson wrote: > Brilliant. > > So the next page to read is > http://techbase.kde.org/Policies/Application_Lifecycle. It explains > the entrance process and the SC vs extragear. > Yes, I've also read that and thank you for your explaination. I believe QtCurve will fit into extragears if it is merged. > Slightly off-topic: If you have QtQuickControls rendering issues, can > you please message me privately with a list of bugs. > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] QtCurve
Brilliant. So the next page to read is http://techbase.kde.org/Policies/Application_Lifecycle. It explains the entrance process and the SC vs extragear. In short we leave this thread for a few days for anyone else to make positive or negative comments about the software entering KDE. Then if everyone approves we merge your code into our repos. It then goes through a mandatory 2 weeks in "kdereview" where people discuss any technical/license/translation issues. Slightly off-topic: If you have QtQuickControls rendering issues, can you please message me privately with a list of bugs. ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] QtCurve
On Mon, Jan 20, 2014 at 9:11 AM, David Edmundson wrote: > I think this makes a lot sense and I would welcome QtCurve into KDE. Thank you for your support. > > Can you read though http://manifesto.kde.org/ and confirm you would > agree to all the commitments > (http://manifesto.kde.org/commitments.html) of a KDE Yes, I've already read them and I agree with all of them. For license, although there isn't any public libraries in QtCurve yet, in order to minimize confision if part of the API in QtCurve is made public (unlikely but possible for configure UI's) I've already relicensed[3] all the code under LGPL instead of GPL two months ago. [3] https://github.com/QtCurve/qtcurve#license project. > > David > ___ > kde-community mailing list > kde-community@kde.org > https://mail.kde.org/mailman/listinfo/kde-community ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] QtCurve
I think this makes a lot sense and I would welcome QtCurve into KDE. Can you read though http://manifesto.kde.org/ and confirm you would agree to all the commitments (http://manifesto.kde.org/commitments.html) of a KDE project. David ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
[kde-community] QtCurve
Hi, My name is Yichao Yu (yuyichao). I started to use KDE as my main DE about one and two years ago and started contributing to some KDE projects soon after including konsole, kdelibs, dolphin etc.. I have recently (about half a year ago) adopted QtCurve[1], a highly configurable theme engine for Qt3, Qt4, Qt5, KWin4 and Gtk2. For those who don't know QtCurve yet, it is the theme engine used by more than half of the widget themes on kde-look. The project was started by Craig Drummond in (or before) 2006 and is now included in most distributions. I would like to move QtCurve to the KDE infrastructure for several reasons. Besides the most obvious ones like making use of the repo, wiki, bug trackers etc. : - As a KDE friendly cross toolkit style engine, this will help me and future QtCurve developer to keep up-to-date with API changes in KDE (e.g. the shadow handling change in 4.8 and the appmenu support in 4.10). - It will also make it easier for KWin developers to make sure their API changes "are sane", especially for the KF5 port. Personally, I have always been hoping to join the KDE community and get involved in the development more. I was not very sure whether QtCurve can fit into the KDE community since kdelibs is just a minor optional dependency and I'm still working on making it to work better outside KDE. However, Martin (the KWin one...) convinced me that KDE is not just a collection of softwares that links to kdelibs or can only run in KDE (the desktop environment) and that's the reason I'm sending this email. Looking forward to hear from you soon. Yichao Yu [1] https://github.com/QtCurve/qtcurve [2] http://kde-look.org/content/show.php?content=40492 ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Plasmoids and Apps - was - Re: Applications in KDE Generation 5
On Sunday, January 19, 2014 23:42:58 Martin Sandsmark wrote: > On Sun, Jan 19, 2014 at 11:55:13AM +0100, Aaron J. Seigo wrote: > > this is not really related at all, and i hesitate to engage in the topic > > here due to loss of topical focus. > > It was merely to illustrate a point, that switching to QML is not a simple > process, I don’t believe anyone intimated it was; the work done to get Plasma there has been more than a master class in that. > and it seemingly takes us over a year (at the very least, since we > still aren't close) to reach feature parity with the old solution. Yes, it takes time and effort. The QWidget UI has a ~20 year legacy behind it, while the QML legacy is quite recent, so this is to be expected. > Therefore I think it's useless to move existing, nicely working applications > (like kcalc) to it for seemingly no good reason at all. I agree that if there is no good reason, then there is no point. Good reasons were offered in the original mail, however, namely duplication of effort and inconsistency due to multiple implementations of what is from a use case perspective the same thing. > > have you worked with the Qt5 QML2 desktop components? > > Yes, I've been playing with the desktop components in Qt 5.2. Hopefully they > will get a lot better before we release anything using them, though, > because things like the file/folder selector is basically unusable in the > current state, at least on the systems I've tested it on. For things like kcalc, the things the desktop components are not good at are irrelevant; the things it *is* good at could radically improve its UI. -- Aaron J. Seigo ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
Re: [kde-community] Retiring applications - was - Re: Applications in KDE Generation 5
On Thu, Jan 16, 2014 at 1:37 AM, Albert Astals Cid wrote: > El Dimecres, 15 de gener de 2014, a les 21:47:17, John Layt va escriure: >> Hi, >> >> * A number of our apps and utilities really have had their day and >> need "retiring", e.g. KsCD, Kppp, KFloppy. There's no point keeping >> low-quality or unmaintained apps around just to try ship a "complete >> desktop experience", especially if there are other better apps out >> there (even if not KDE ones). Being part of the official release >> should be a stamp of quality: make apps work for it. Lets go through >> the existing apps and agree what needs dropping to Extragear or >> Unmaintained. > > I am not conviced by that, we probably still have some users for that and i'm > pretty sure some of those apps still get roaming fixes from people, if you > move them out from the "apps we release on each release", you'll end up with > the K3b situation, an application that has had bugfixes but hasn't had a > release in ages so noone is beneffiting from those bugfixes because there's > noone around that has enough "power" to do a release. Random ramblings of the day: Getting the odd fix here and there does not related in any form or fashion to the quality though. If any of the people doing the k3b fixes cared enough I am sure they had done a release. It's not like only someone who got themselves a maintainer badge can do releases after all. The problem however is that the applications John mentioned, are hard to crowd maintain (i.e. put on life support and everyone feels jointly responsible for the quality of those applications, thus providing rather sensible releases) because they require hardware and/or special knowledge. Kppp for example, I'd totally throw random fixes at it except it is nigh impossible to test this thing accurately because I have no physical modem and no knowledge of how the ppp stack would or should work in general. Same goes for kfloppy. It'd be jolly hard to find anyone who still has a working floppy drive and can use it on a machine new enough to run an up-to-date system. Keeping *actually* unmaintained software in monthly releases creates the wrong impression. We really are lying to the user and ourselves here. We create the impression that kppp is actively being maintained and cared for while in fact it is not [1][2]. Now that fact is easy enough to ignore for everyone who does not need to use kppp. For everyone who does it's basically a slap in the face a la 'got ya, we are not really maintaining this, just wanted to have you spend time on filing a bug report that will not ever see a reply from a dev'. It is not nice, and it is not fair. If the people doing fixes to such half-dead software actually stepped up and took over maintenance, the software would not be unmaintained and didn't need to get dropped out of the SC; also the world would be a much better place. [1] http://quickgit.kde.org/?p=kppp.git&a=shortlog&h=ab56f7593087179ceeef28ae8e70e1cdae8faf3c [2] https://bugs.kde.org/buglist.cgi?product=kppp&component=general&resolution=---&list_id=909065 HS ___ kde-community mailing list kde-community@kde.org https://mail.kde.org/mailman/listinfo/kde-community
