Re: sentry evaluation
I didn't know we had Sentry! How can we get crash reports from KDE Connect through it? That would be super useful. I've used Sentry in the past for other projects and I see a big value in it. Actually, in the case of the KDE Connect Android app, we already get crash reports aggregated by popularity by default via the Play Store. Same with the Windows version published in the Windows Store. It's very useful to fix the most common crashes, and it would be great to have something like that for Linux as well. About the alternative of using bugzilla for crashes: We can't know how common a crash is with the crashes that seldomly get uploaded to bugzilla. So +1 for keeping Sentry.
Re: Gitlab Turn-off Issues
On Sun, Jun 28, 2020, 20:29 Ben Cooksley wrote: On Mon, Jun 29, 2020 at 4:28 AM Allen Winter wrote: > > Can we remove the Issues feature on all invent projects? > We're starting to see more and more people adding Issues. > > For KOrganizer, bshah replaced Issues with Bugzilla. > > I very much doubt we want or are ready to replace Bugzilla. As has been discussed *far too many times* already, we have NO INTENTION to replace Bugzilla at this stage. This matter has been discussed on many threads, including on this list in the past. Issues on Gitlab is intended to be the replacement for Phabricator Tasks. Disabling them would leave projects with no developer task management functionality, which would be highly undesirable as they are heavily used by a number of projects. What prevents a user from seeing a link labeled "issues" and thinking "this is where I report my issues with this product"? Currently, nothing, so I've decided to accept that bugs now come from two places: Bugzilla and Gitlab issues. > > Your request to disable them for all KDE projects is therefore declined. > > Regards, > Ben Cooksley > KDE Sysadmin >
Re: Update on Status of Gitlab Migration
On Sat, Apr 11, 2020 at 11:36 AM Ben Cooksley wrote: > > Good morning Community, > > I'm pleased to report that this week we reached a major milestone, > with all the necessary technical components now being in place on our > side for our migration to Gitlab to take place. Regarding this: is the subdomain going to stay invent.kde.org once we have officially moved? I find it's a bit confusing to use that instead of gitlab.kde.org Albert
Re: HiDPI issues with KDE applications
If this has to be done for all apps, why isn't it done at Qt level? On Sat, Sep 28, 2019 at 5:05 PM Christoph Cullmann wrote: > > Hi, > > I just checked again the HIDPI support of Kate/KWrite on Windows and it > "sucked". > > It seems we never properly did setup the stuff to auto-scale, e.g. the > > QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling, true); > > call was missing, we only had the > > QCoreApplication::setAttribute(Qt::AA_UseHighDpiPixmaps, true); > > part that we sprinkled in most of KDE's things in the past. > > I now rectified that for Kate/KWrite, shall we do this for all our > applications? > > Greetings > Christoph > > -- > Ignorance is bliss... > https://cullmann.io | https://kate-editor.org
Re: Possible to move some KF5 frameworks to invent?
On Mon, Aug 12, 2019, 18:46 Ben Cooksley wrote: > On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora > wrote: > > > > Could we use sysadmin/repo-metadata to know which branch is stable and > therefore should be protected and trigger the hooks for closing bugs, etc? > > Unfortunately that only tells us what the current stable branch is - > it doesn't let us know what the other (either historical or up and > coming) stable branches are called. > Maybe that is enough? IMO, it makes sense to not consider a bug is closed until the commit that fixes it has been merged to either master or the current stable branch.
Re: Possible to move some KF5 frameworks to invent?
Could we use sysadmin/repo-metadata to know which branch is stable and therefore should be protected and trigger the hooks for closing bugs, etc? On Mon, Aug 12, 2019, 17:39 Ben Cooksley wrote: > On Mon, Aug 12, 2019 at 6:24 PM Kevin Ottens wrote: > > > > Hello, > > Hi Kevin, > > > > > On Sunday, 11 August 2019 22:14:19 CEST Albert Astals Cid wrote: > > > With phabricator you can do a "force push" to your review[1], with > gitlab > > > you can not[2]. > > > [...] > > > [2] without having your own fork of a repository, that is annoying for > > > various reasons > > > > I'm genuinely surprised about that claim. Are we sure that it's not a > setting > > on our instance forcing this? I'm currently working on a project where > you can > > force push in non-protected branches without your own fork. > > Our hooks prevent force pushes from taking place within our mainline > repositories. > > This is done for a couple of reasons. > > The first, that in order for us to reliably operate things like > closing of bugs on Bugzilla and sending emails and IRC Notifications, > it is necessary for the hooks to be able to detect when a commit is > "new" and therefore needs to be processed for this sort of action. > Unfortunately due to how Git works, there is no difference between a > genuinely new commit, and one that has simply been rebased - they're > both "new" as far as the hooks are concerned. This means we cannot > allow rebasing within any branch which is subject to notification or > other hook processing. > > The second, is that recovering your work when someone has > rebased/force pushed the branch underneath you, is something which is > non-trivial unless you are familiar with the process. Even for those > who are experienced, it is possible to make mistakes in the process of > doing so, and either lose commits or mangle the metadata associated > with the commit (such as the authorship information - an incident > which happened earlier this year). At the time KDE migrated to Git it > was decided on a community wide basis that familiarity with this isn't > something we should expect casual contributors to have. > > Those familiar to Git will be aware that it is very much possible to > limit the scope of hooks like our Notification hooks, while still > allowing them to be caught when entering branches that are subject to > Notification. At this time the only proposals i've seen for this have > been for "everything but master and stable branches" which > unfortunately is not a scalable solution we can support due to the > significant variance in schemes used for naming stable branches across > different projects (not without pushing the maintenance role for > handling all these different naming schemes on to Sysadmin) > > > > > Regards. > > -- > > Kevin Ottens, http://ervin.ipsquad.net > > > > enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en > > Regards, > Ben >
Re: konqueror.org
Killing some satellite websites will ease the maintenance, though, so I'm with Jonathan. The screenshots being so old seem a prof to me that its being hard for us as a community to keep up with it. Albert On Sun, Jun 2, 2019, 12:34 Albert Astals Cid wrote: > El dissabte, 1 de juny de 2019, a les 13:07:41 CEST, Jonathan Riddell va > escriure: > > Can you call konqueror.org website unmaintained? The screenshots are > all > > from KDE 4 times. We can just make it forward to the new > > kde.org/applications page instead > > Or just update the screenshots and all its contents are still valid and > much more complete than whatever is there in kde.org/applications. > > Cheers, > Albert > > > > > Jonathan > > > > > > >
Re: Review Request 110430: [Taskbar applet] Added actions to be perfomed on middle click
On May 15, 2013, 6:06 a.m., Aaron J. Seigo wrote: I am not in favour of this patch for a couple of reasons. First, there is a port underway to QML which does not need to be delayed further by adding more features. More importantly, however, middle click is a special case of not the first two mouse buttons (should we support N button mice?) and it adds yet more configuration to an already complex and full configuration dialog. It also conflicts with the meaning of middle click to expand / collapse groups (a fairly hidden feature I also was not particularly happy with tbh). Hello Aaron and thank for your reply. Let me defend the inclusion of this patch from the problems you mention: - Difficulty to port to QML: This feature is implemented in a ~10 lines switch (not counting the GUI-related code), so porting it should not be a problem (I could do it, if needed). - Support for N button mice: The desktop should adapt to the current hardware, and nowadays most mice have 3 buttons (not N, but neither only 2). Moreover, lots of apps have adopted the behaviour of closing tabs with a middle click, so adding this feature for applications in the taskbar is consistent with them. - Complexity of the configuration dialog: I agree that we should try to keep all the configuration dialogs simple, but not adding new features because of that reminds me of Gnome3 ;) I think this is not solution for the long-discussed problem of the user-friendliness. Finally, and more important, it has 2 open bugs (+ 4 duplicates) so there are real users requesting it. If it's not going to be added, those bugs should be marked as wontfix. - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110430/#review32545 --- On May 14, 2013, 10:35 p.m., Albert Vaca Cintora wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110430/ --- (Updated May 14, 2013, 10:35 p.m.) Review request for kde-workspace and Plasma. Description --- This patch adds a feature present in KDE3 and requested by some users (see open bugs), that is performing an action when a taskbar entry is middle-clicked. I have added three possible actions: Close the application, hide it or move it to the current desktop, where the first two were user requests. This addresses bugs 182689 and 190951. http://bugs.kde.org/show_bug.cgi?id=182689 http://bugs.kde.org/show_bug.cgi?id=190951 Diffs - plasma/desktop/applets/tasks/tasks.h fe79a12 plasma/desktop/applets/tasks/tasks.cpp 0a86dcf plasma/desktop/applets/tasks/tasksConfig.ui 6f3ff18 plasma/desktop/applets/tasks/windowtaskitem.cpp f840076 Diff: http://git.reviewboard.kde.org/r/110430/diff/ Testing --- Manual testing. Thanks, Albert Vaca Cintora
Re: Review Request 110430: [Taskbar applet] Added actions to be perfomed on middle click
On May 15, 2013, 6:06 a.m., Aaron J. Seigo wrote: I am not in favour of this patch for a couple of reasons. First, there is a port underway to QML which does not need to be delayed further by adding more features. More importantly, however, middle click is a special case of not the first two mouse buttons (should we support N button mice?) and it adds yet more configuration to an already complex and full configuration dialog. It also conflicts with the meaning of middle click to expand / collapse groups (a fairly hidden feature I also was not particularly happy with tbh). Albert Vaca Cintora wrote: Hello Aaron and thank for your reply. Let me defend the inclusion of this patch from the problems you mention: - Difficulty to port to QML: This feature is implemented in a ~10 lines switch (not counting the GUI-related code), so porting it should not be a problem (I could do it, if needed). - Support for N button mice: The desktop should adapt to the current hardware, and nowadays most mice have 3 buttons (not N, but neither only 2). Moreover, lots of apps have adopted the behaviour of closing tabs with a middle click, so adding this feature for applications in the taskbar is consistent with them. - Complexity of the configuration dialog: I agree that we should try to keep all the configuration dialogs simple, but not adding new features because of that reminds me of Gnome3 ;) I think this is not solution for the long-discussed problem of the user-friendliness. Finally, and more important, it has 2 open bugs (+ 4 duplicates) so there are real users requesting it. If it's not going to be added, those bugs should be marked as wontfix. Aaron J. Seigo wrote: porting it should not be a problem (I could do it, if needed). that is definitely a point in your favor. assuming this feature addition is accepted: there's little point to putting it in the c++ version, however, only to put it later in the qml version (which is supposed to be in 4.11). so putting it directly in the QML version would make the most sense. Moreover, lots of apps have adopted the behaviour of closing tabs with a middle click to point out the obvious: windows are not tabs. this also implies that middle click to close is actually a *good* feature. i think it is for power users .. but i have seen too many instances where these kinds of magic click that button and magically something happens features lead to confusion, and confusion leads to distrust of the system as a whole. yes, the default is to do nothing in your patch (+1 for that), but if sitting down to someone else's system results in wildly unpredictable behaviour ... keep in mind this is not a random component, but a default part of every plasma desktop installation, so it has to work better than most. how much faster is middle click versus right-click-close? fast enough to warrant the risk of surprising behaviour for people who aren't expecting it? Complexity of the configuration dialog: I agree that we should try to keep all the configuration dialogs simple currently that page has 11 settings. ad-hoc testing i've done in the past hints that many of these settings are already not understandable to many users. i really don't want to make this worse. several of the plasmoids have room for more options. the taskbar, folderview, clock and system tray are four that really don't. adding feature over feature is leading to an increasing mess that nobody cares to clean up. if this patch introduced a re-think of the configuration presentation so that it is easier to understand and more approachable, i would consider that a fair trade for accepting a feature i'm not particularly in favour of :) but not adding new features because of that reminds me of Gnome3 for future reference: when i see this kind of statement made, i usually add -1 to my overall weighting. i do not agree with many design decisions in other projects, but design can not be done well if it is primarily directed by not being that other group. common sense and reasoning should be applied to each case without the justification of not like them, otherwise we just create the opposite kind of error. it has 2 open bugs (+ 4 duplicates) so there are real users requesting it. for any product with a large enough user base, given enough time and an open feature request tracker, any possible feature will be requested (usually multiple times). this means that any feature, regardless of intrinsic value, can be justified using this argument. (the least useful case of this i've seen is when people submit the feature request, then later a patch and then use the feature request as evidence it is wanted ;) Martin
Review Request 110430: [Taskbar applet] Added actions to be perfomed on middle click
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110430/ --- Review request for kde-workspace. Description --- This patch adds a feature present in KDE3 and requested by some users (see open bugs), that is performing an action when a taskbar entry is middle-clicked. I have added three possible actions: Close the application, hide it or move it to the current desktop, where the first two were user requests. This addresses bugs 182689 and 190951. http://bugs.kde.org/show_bug.cgi?id=182689 http://bugs.kde.org/show_bug.cgi?id=190951 Diffs - plasma/desktop/applets/tasks/tasks.h fe79a12 plasma/desktop/applets/tasks/tasks.cpp 0a86dcf plasma/desktop/applets/tasks/tasksConfig.ui 6f3ff18 plasma/desktop/applets/tasks/windowtaskitem.cpp f840076 Diff: http://git.reviewboard.kde.org/r/110430/diff/ Testing --- Manual testing. Thanks, Albert Vaca Cintora
