Re: CuteHMI in kdereview
Hi, Kevin Funk wrote: I think you're beating a dead horse here. The ship has sailed. I am aware all of that Don't get me wrong. I don't want to turn the tide and convince you to use Qbs instead of CMake. I'm just pointing out: maybe take a look at this nuclear-powered ship prototype, even tho' it hadn't left the docks. Have been asked about Qbs, so I explained my point of view. No reason to be concerned :P You'll be missing out on quite a bit of tooling which is implemented in KDE's Extra CMake Modules framework: https://github.com/KDE/extra-cmake-modules (part of that is all the translation handling) It may be hard to accomplish with CMake. Yeah, I have been looking at ECM. It's all well done etc, but what I meant by "components" are components like QML components. I've been using CMake in my projects for many years, so I can compare the two. I'm not a Qbs fanboy. CMake has its pros and advantages, but its language lacks constructs like structures/classes/records, inheritance etc (don't want to start another offtopic here, but I think we can all agree that CMake language is a bit limited and its syntax is quaint...). Then, I have deliberately written **something like** Qbs (not just Qbs). I mentioned Qbs has some issues (I didn't want to elaborate, to not make an offtopic, but here we are...), most important of which is that it isn't built on top of QQmlEngine and it's not QML, but merely a QML dialect. Imagine a proper QML-based build system, into which you could import standard QML extensions. Integrity is something we're missing nowadays. Still Qbs product definition files are clean and unmatched in terms of readability, thus I think it paves the way for next-gen build system, which will eventually replace CMake. I hope Qbs controversy is clarified now Regards, Michal sob., 15 lut 2020 o 14:11 Kevin Funk napisał(a): > On Thursday, 13 February 2020 11:00:27 CET Michal Policht wrote: > > Yeah, I neglected translations a bit... I am going to implement adequate > > Qbs module for extracting translations. > > Heya, > > > When it comes to Qbs, it's not dead. Community has taken over the > > project, there's active development and recent version was released just > > 44 days ago. > > > > We migrated from QMake to Qbs, when it was still supported by Qt Company > > and promoted as official build system for Qt 6. Thus we assumed Qbs is > > the future. We've found that Qbs has some issues (like every software), > > but in overal it's very capable and powerful piece of software. It also > > provides much faster builds on Windows. I wish more people would give it > > a try before burying the project, to at least see the potential. With > > something like Qbs we could create a build framework with reusable > > components, so that each KDE subproject could benefit from it and become > > naturally integrated. > > I think you're beating a dead horse here. The ship has sailed. > > You'll be missing out on quite a bit of tooling which is implemented in > KDE's > Extra CMake Modules framework: > https://github.com/KDE/extra-cmake-modules > (part of that is all the translation handling) > > There's also no support for building QBS projects on KDE's CI: > https://build.kde.org > > > It may be hard to accomplish with CMake. > > What exactly? I mean it's all there already. > > > Regards, > > PS: Qt's CMake-based build system just got merged into qtbase dev branch a > few > days ago. > > Regards, > Kevin > > > > Michal > > > > > El dilluns, 3 de febrer de 2020, a les 17:57:24 CET, Michal Policht va > escriure: > > >> Hello there, > > >> > > >> CuteHMI (https://cutehmi.kde.org/) has been moved to kdereview. > > > > > > It has no Messages.sh for translation extraction. > > > > > > Any particular reason you're using a dead build system none of our > > > projects uses? > > > > > > Cheers, > > > > > > Albert > > >> > > >> CuteHMI is meant to be a set of tools and components that help one to > > >> create QML-based HMI/SCADA software. > > >> > > >> The project has been started few years ago, because I couldn't find > any > > >> open-source, QML-based HMI/SCADA framework I could put my things into. > > >> > > >> Regards > > >> > > >> Michal Policht > > > -- > Kevin Funk | kf...@kde.org | http://kfunk.org
Re: Banning QNetworkAccessManager
Hi, as Volker said, without any alternative, we can't just ban QNAM. And even with one, we would need time to implement it (for example, for GCompris, this part of the code was written by someone who is less active now, so rewriting it, testing it and be sure it works will take some time). Can't we use lxr to find all applications using it, check if they use it in a good way or not instead? Johnny Le mer. 19 févr. 2020 à 10:05, Ben Cooksley a écrit : > > On Wed, Feb 19, 2020 at 9:30 PM Volker Krause wrote: > > > > On Wednesday, 19 February 2020 08:05:01 CET Ben Cooksley wrote: > > > On Mon, Feb 3, 2020 at 7:42 AM Volker Krause wrote: > > > > I agree on the problem of QNAM's default, see also > > > > https://conf.kde.org/en/ > > > > akademy2019/public/events/135 on that subject. > > > > > > > > On Saturday, 1 February 2020 23:24:14 CET Ben Cooksley wrote: > > > > [...] > > > > > > > > > Prior to now, i've taken the approach of advertising that > > > > > QNetworkAccessManager is broken and needs a flag set within > > > > > applications when used, however unfortunately this seems to have been > > > > > an ineffective approach and cases of broken behaviour continue to > > > > > appear (despite this brokeness being known about and advertised since > > > > > back in the Qt 4.x series when this class was introduced) > > > > > > > > > > Therefore, given the Qt Project is unlikely to change their position > > > > > > > > > on this, I would like to propose the following: > > > > The Qt Project is actually in favor of changing at least the redirection > > > > default to exactly what we want it to be. > > > > https://codereview.qt-project.org/c/qt/qtbase/+/273175 has the change, > > > > and > > > > got approval both by Lars and one of the maintainers. It is merely stuck > > > > in dealing with the unit test fallout in Qt's CI that somebody has to > > > > take care of. Doesn't immediately help us of course, but claiming Qt is > > > > unwilling to change this is simply wrong. > > > > > > > > > 1) That effective immediately, QNetworkAccessManager and it's children > > > > > classes be banned and prohibited within KDE software, to be enforced > > > > > by server side hooks. > > > > > 2) That we fork QNetworkAccessManager and the associated classes > > > > > within the appropriate Framework (to be determined), where the > > > > > defective behaviour can then be corrected. > > > > > > > > While this might solve the redirection problem, it brings us yet another > > > > then unmaintained HTTP implementation next to the one in KIO, which is a > > > > far bigger problem long term. We need less of those, not more. > > > > > > > > To address the problem of people not using the correct defaults, I did > > > > propose a much less extreme approach in the above mentioned talk at > > > > Akademy, namely having a KNetworkAccessManager as a sub-class of QNAM in > > > > a low-tier frameworks that essentially just enables redirects and HSTS. > > > > QNAM's implementation isn't the problem after all, the defaults are. > > > > > > > > Commit hooks warning about QNAM usage might still be a good idea, but > > > > as a > > > > warning only. Hard blocking QNAM-using code would block at least three > > > > repos I spend a lot of time on currently, none of which even talks to > > > > KDE > > > > servers. > > > > > > > > If you need to take more drastic measures against code not doing this > > > > correctly regardless, you can do that my dropping the server-side > > > > workarounds. Yes, that would break the affected application possibly, > > > > but > > > > at least it would not cause massive collateral damage for the people > > > > using this correctly. > > > > > > > > It would also help to know where specifically we have that problem, so > > > > we > > > > can actually solve it, and so we can figure out why we failed to fix > > > > this > > > > there earlier. > > > > > > Just bringing this up again - it seems we've not had much movement on > > > this aside from the Wiki page. > > > > > > Examining that Qt merge request, it not only is targeted at just Qt > > > 6.x, it also hasn't had any movement since the start of October 2019 - > > > 4 months ago. > > > Given that we are going to be on Qt 5.x for some time, that merge > > > request can't be considered to be the 'fix' for this issue. > > > > The targeting of Qt6 is due to this aiming at dev when that was still Qt > > 5.x, > > but you are right of course, somebody needs to do the work there to drive > > this > > to completion, no matter in which version it will actually land. > > Indeed. > > > > > > We need a solution that will ensure software released today doesn't > > > cause us pain in several years time, because as I illustrated in an > > > earlier email to this thread, software has a habit of remaining in use > > > for an extremely long amount of time (August 2014 being the release > > > date of the Marble versions in question hitting that old URL). > > > > > > The easiest
Re: Review Kid3
Hi Christoph, >> You should change the bug reporting to use bugzilla not your email address in KAboutData > > Right. Urs, could you please request creation of a bugzilla product? I discussed the migration of the existing bug reports, feature requests and help form items with Jonathan, and we agreed that GitLab issues ( https://invent.kde.org/kde/kid3/issues) are used for this purpose. All existing issues from SourceForge have been migrated to GitLab and the source code is fixed to point to this location. Regards, Urs
Plasmashell Folderview "refresh"
hello everybody, after mounting a sambashare the corresponding folderview widget obviously gets informed because it changes the "title" to "xy on 10.0.0.100" but it doesn't refresh it's content. i guess this is a bug with remote filesystems and i'm going to create a new bugreport but i have a specific question concerning the folderview widget. is it possible to trigger a folderview refresh from within a terminal (script) ? i'm searching qdbus for hours now and it seems i'm not able to find a way to get to the widgets and "talk" to them... probably with "plasmascript" ?? thx in advance cheers thomas
