Re: Should we stop distributing source tarballs?

It seems a lot of people feel conservative in favor of tarballs, so maybe I aimed too far. At least I think the discussion brought some interesting points that we can explore further. Some I identified: - The tarballs should contain no changes with respect to git, or minimal changes obviously

Should we stop distributing source tarballs?

Hi KDE folks, The recent xz backdoor scandal made me realize how bad and obsolete distributing tarballs is. The source of truth for our code are the repositories, and releases can simply be tags on those repos. As a big free software community, I think we should lead by example and get rid of

Re: [announcement] Telegram bridging to be retired Wed. 20 Sept. | 5 to-dos

KDE Connect has a Telegram group with 660 members (vs 100 on matrix). I don't know if we are the exception with such a big group on Telegram, but this is going to be a hit to our community :( On Tue, 22 Aug 2023, 09:02 Joseph P. De Veaugh-Geiss, wrote: > Hello KDE community, > > apologies for

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

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

D26888: work around to fully support the windows backend

albertvaka added a comment. @vonreth @broulik Can you folks give this a final review? We have been building KDE Connect for Windows off a custom branch with this patch, but I would like to use official builds of KNotifications so it would be great if we can merge it. REPOSITORY R289

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

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

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

D27210: add KDEconnect Icons

albertvaka added a comment. Hey, thanks for working on this! A "brand" re-design is something that we could really use. One of the things that I would like to change from the current icon/logo, though (and that this new one doesn't change), is the fact that there is a mobile phone in

D26888: work around to fully support the windows backend

albertvaka added inline comments. INLINE COMMENTS > notifybysnore.cpp:135-139 > +if (id == -1) { > +emit actionInvoked(0, actionNum); > +} else { > +emit actionInvoked(id, actionNum); > +} This could become: if (id == -1) {

Re: Sysadmin Load Reduction: Subversion Infrastructure

On Sat, Nov 9, 2019 at 6:53 PM Ben Cooksley wrote: > > Unfortunately Rosetta does not have the necessary free disk space, as > the Subversion repository is approximately 80GB these days in size, > and operating WebSVN requires a full copy of the Subversion repository > locally in order to

How to prevent users from opening GitLab issues?

As we transition to Gitlab, our users find two different ways of reporting issues: in Bugzilla and in Gitlab. Since we don't have plans to deprecate bugzilla, is there any way we can disable issues in Gitlab? 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

D23694: Add support for sshfs to the fstab backend

albertvaka added a comment. If it's a problem for kdeconnect mounts to appear there, how can we hide it? It's an sshfs mountpoint like any other, only that it is mounted programmatically. REPOSITORY R245 Solid REVISION DETAIL https://phabricator.kde.org/D23694 To: lbeltrame, bruns,

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

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

D22580: Notify users when not using KDE_INSTALL_USE_QT_SYS_PATHS about prefix.sh

albertvaka accepted this revision. This revision is now accepted and ready to land. REPOSITORY R240 Extra CMake Modules BRANCH master REVISION DETAIL https://phabricator.kde.org/D22580 To: apol, #frameworks, albertvaka Cc: albertvaka, kde-frameworks-devel, kde-buildsystem, LeGast00n,

D22580: Notify users when not using KDE_INSTALL_USE_QT_SYS_PATHS about prefix.sh

albertvaka added inline comments. INLINE COMMENTS > KDEInstallDirs.cmake:721 > +if(NOT KDE_INSTALL_USE_QT_SYS_PATHS) > +message(NOTICE "Installing in ${CMAKE_INSTALL_PREFIX}, remember set the > environment. See ${CMAKE_CURRENT_BINARY_DIR}/prefix.sh") > +endif() Installing in

D22105: WIP : Fix SFTP Plugin of KIO for Windows

albertvaka added inline comments. INLINE COMMENTS > brute4s99 wrote in kio_sftp.cpp:2257 > yes! thanks Hannah!  You can keep QT_STAT_LNK on every platform and remove the ifdef. That's the point of the abstraction Qt provides. For consistency, I would also change the other (S_IFDIR, etc.) to

D22105: WIP : Fix SFTP Plugin of KIO for Windows

albertvaka added inline comments. INLINE COMMENTS > andriusr wrote in kio_sftp.cpp:2257 > I'm not sure what is intended to achieve here, the remote file _can_ be a > symlink, and IIRC when we had sftp on dolphin in KDE4 those symlinks were > shown as such. I think what they mean is that if

D21369: [WIP] Add AbstractContact properties for KContact::PhoneNumber objects

albertvaka added a comment. If I understand correctly, the only reason to use KContacts here is so we can use its PhoneNumber type. We could change it to a QString? REPOSITORY R307 KPeople REVISION DETAIL https://phabricator.kde.org/D21369 To: sredman, apol Cc: albertvaka,

D21661: add snoretoast backend for KNotifications on Windows

albertvaka added inline comments. INLINE COMMENTS > notifybysnore.h:45 > +QMap> m_notifications; > +QString program = QStringLiteral("SnoreToast.exe"); > +QLocalServer *server; Isn't LibSnore abstracting this? Why do we need to call the exe instead of using some method in LibSnore?

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

D16951: Add mouse button icons

albertvaka added a reviewer: KDE Connect. REPOSITORY R266 Breeze Icons BRANCH mouse-buttons (branched from master) REVISION DETAIL https://phabricator.kde.org/D16951 To: ndavis, #vdg, ngraham, nicolasfella, #kde_connect Cc: trickyricky26, abetts, ngraham, rizzitello, nicolasfella,

D16692: A QApplication object needs to be instantiated for kio-kdeconnect to work on KDE Neon

albertvaka added a comment. In D16692#355068 , @fvogt wrote: > In D16692#355067 , @albertvaka wrote: > > > In D16692#354990 , @fvogt wrote: > > > > >

D16692: A QApplication object needs to be instantiated for kio-kdeconnect to work on KDE Neon

albertvaka added a comment. In D16692#354990 , @fvogt wrote: > I'm wondering why this specifically mentions "KDE Neon" both in the title and in the commit message. > > Is this workaround/fix only needed on neon or is the message wrong?

D16692: A QApplication object needs to be instantiated for kio-kdeconnect to work on KDE Neon

This revision was automatically updated to reflect the committed changes. Closed by commit R224:560e8638e8dd: A QApplication object needs to be instantiated for kio-kdeconnect to work on… (authored by eduisters, committed by albertvaka). REPOSITORY R224 KDE Connect CHANGES SINCE LAST UPDATE

D16189: kio_help: Fix crash in QCoreApplication when accessing help://

albertvaka added a comment. Old apps that didn't have a QApplication are broken by this version of KIO. Definitely a regression to me :/ REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D16189 To: mpyne, #frameworks, sitter, dfaure, broulik Cc: sredman, albertvaka,

D16692: A QApplication object needs to be instantiated for kio-kdeconnect to work on KDE Neon

albertvaka accepted this revision. albertvaka added a comment. This revision is now accepted and ready to land. Let's ship this, but I still think we should see if something can be done on the KIO side to not break old apps. REPOSITORY R224 KDE Connect BRANCH kde-neon REVISION DETAIL

D16189: kio_help: Fix crash in QCoreApplication when accessing help://

albertvaka added a comment. As I commented in this similar patch (https://phabricator.kde.org/D16692 ) I think this is a regression that should be fixed in KIO. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D16189 To: mpyne, #frameworks, sitter, dfaure, broulik Cc:

D16692: A QApplication object needs to be instantiated for kio-kdeconnect to work on KDE Neon

albertvaka requested changes to this revision. albertvaka added a comment. This revision now requires changes to proceed. In my opinion this is a regression in KIO and it would be nice to check if it can somehow be fixed there: Upgrading KIO should not break existing apps. Even if we

D11683: Make it possible to request a plugin configuration module programatically

albertvaka accepted this revision. albertvaka added inline comments. This revision is now accepted and ready to land. INLINE COMMENTS > kpluginselector.h:214 > + * Shows the configuration dialog for the plugin @p pluginId if it's > available > + */ > +void showConfiguration(const

D6906: Create a "." entry even on empty dirs

albertvaka added a comment. Mmmm it could be because kio_desktop is a ForwardingSlave, so the entry is added first by its forwardee (kio_file I think) and then again by kio_desktop itself? I'm not sure if what I'm saying even makes sense because I don't really know how KIO works. Will

D6906: Create a "." entry even on empty dirs

albertvaka added a comment. Reverted the patch. Couldn't figure out what is wrong with it though... I don't think that "." is being emitted multiple times because of this patch. It looks more like if kio_desktop was causing listEntries to be called twice. REPOSITORY R241 KIO REVISION

D6906: Create a "." entry even on empty dirs

This revision was automatically updated to reflect the committed changes. Closed by commit R241:0ac78aa3fba4: Emit a "." UDSEntry when not present, even on empty directories. (authored by albertvaka). REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE

D6906: Create a "." entry even on empty dirs

albertvaka added a reviewer: elvisangelaccio. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D6906 To: albertvaka, #frameworks, elvisangelaccio

D6906: Create a "." entry even on empty dirs

albertvaka edited the summary of this revision. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D6906 To: albertvaka, #frameworks

D6906: Create a "." entry even on empty dirs

albertvaka created this revision. Restricted Application added a project: Frameworks. REVISION SUMMARY Fixes bug 382046 REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D6906 AFFECTED FILES src/core/slavebase.cpp To: albertvaka, #frameworks

[Differential] [Abandoned] D4663: Allow setting the timeout value.

albertvaka abandoned this revision. albertvaka added a comment. I'm discarding this patch and will find an alternative way to solve the problem in KDE Connect. I still think, though, that notifications are a way better solution to require interaction from the user than SNIs, so I don't

[Differential] [Commented On] D4663: Allow setting the timeout value.

albertvaka added a comment. I agree that just rising the timeout is suboptimal but I still like it better than a modal dialog... Actually, notifications were invented as a way to avoid harassing the user with modal dialogs when apps need attention. Apart from that, and even if we end up

[Differential] [Commented On] D4663: Allow setting the timeout value.

albertvaka added a comment. I don't think indicators are the future of notifications :/ If you have a look at modern systems like Android (which had the luxury of designing a notification system without having to think about legacy), they have nothing like app indicators: they use

[Differential] [Commented On] D4663: Allow setting the timeout value.

albertvaka added a comment. I understand the potential of it being misused, even though I don't think we should treat developers as if they didn't know what they are doing. Also, if we want to have a maximum timeout, this is something that should be enforced on the server (ie: Plasma)

[Differential] [Updated] D4663: Allow setting the timeout value.

albertvaka added a reviewer: apol. REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D4663 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: albertvaka, #frameworks, apol Cc: #frameworks

[Differential] [Request, 43 lines] D4663: Allow setting the timeout value.

albertvaka created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REPOSITORY R289 KNotifications BRANCH master REVISION DETAIL https://phabricator.kde.org/D4663 AFFECTED FILES src/knotification.cpp

[Differential] [Updated] D4663: Allow setting the timeout value.

albertvaka added a reviewer: Frameworks. REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D4663 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: albertvaka, #frameworks Cc: #frameworks

[Differential] [Closed] D4213: Mark non-persistent notifications as transient.

This revision was automatically updated to reflect the committed changes. Closed by commit R289:579b75aac8e2: Mark non-persistent notifications as transient. (authored by albertvaka). REPOSITORY R289 KNotifications CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D4213?vs=10371=10423

[Differential] [Updated] D4213: Mark non-persistent notifications as transient.

albertvaka added a reviewer: Frameworks. REPOSITORY R289 KNotifications REVISION DETAIL https://phabricator.kde.org/D4213 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: albertvaka, #frameworks Cc: #frameworks

[Differential] [Request, 4 lines] D4213: Mark non-persistent notifications as transient.

albertvaka created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY On Gnome and other desktops using their extension of the notifications spec, notifications are persistent unless they set the transient

[Differential] [Closed] D4142: Support "default actions", as specified in [1].

This revision was automatically updated to reflect the committed changes. Closed by commit R289:8b161b971fae: Support "default actions", as specified in [1]. (authored by albertvaka). REPOSITORY R289 KNotifications CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D4142?vs=10186=10258

[Differential] [Commented On] D4142: Support "default actions", as specified in [1].

albertvaka added a comment. In https://phabricator.kde.org/D4142#77834, @broulik wrote: > Care needs to be taken that existing notifications don't suddenly behave differently but that moving from actions() to defaultAction() is a conscious and explicit choice in the application that

[Differential] [Request, 57 lines] D4142: Support "default actions", as specified in [1].

albertvaka created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY Default actions are the actions triggered when the notification is simply clicked, without adding any "action buttons". Until now, with

[Differential] [Commented On] D2545: Cleanup KSharedUiServerProxy before qApp exists

albertvaka added a comment. Since there is no fix on Qt, should we merge this? BRANCH master REVISION DETAIL https://phabricator.kde.org/D2545 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: kfunk, vonreth, dfaure Cc: albertvaka, mutlaqja,

[Differential] [Commented On] D2546: Cleanup DBus-related resources before qApp exits

albertvaka added a comment. Since there is no fix on Qt, should we merge this? REVISION DETAIL https://phabricator.kde.org/D2546 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: kfunk, vonreth, dfaure Cc: albertvaka, #frameworks

Re: Review Request 127169: By default, make KDE_INSTALL_USE_QT_SYS_PATHS share the same directory scheme as Qt if they share the prefix

a lot of sense to install things in the same places as Qt, especially when Qt has to find the stuff we install. - Albert Vaca Cintora On feb. 24, 2016, 9:09 a.m., Aleix Pol Gonzalez wrote: > > --- > This is an automatically ge

Re: [Kde-hardware-devel] Review Request 123263: WIP: KDE Connect backend for Solid

: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123263/ --- (Updated July 31, 2015, 12:15 p.m.) Review request for kdeconnect, Solid, Albert Vaca Cintora, and Emmanuel Pescosta

Re: [Kde-hardware-devel] Review Request 123263: WIP: KDE Connect backend for Solid

something? Besides that, I think we need to fix the issues opened by Lamarque and Alex, but looks good to me :) - Albert Vaca Cintora On abr. 5, 2015, 1:56 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail

Re: [Kde-hardware-devel] Review Request 123263: WIP: KDE Connect backend for Solid

: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123263/ --- (Updated abr. 5, 2015, 1:56 p.m.) Review request for kdeconnect, Solid, Albert Vaca

Re: Review Request 122206: [kio] Make tests optional

On March 16, 2015, 8:37 p.m., Albert Vaca Cintora wrote: I know this is merged already but this patch is being applied to every KDE package and I want to keep the discussion in a single place. We already have a toggle option in CMake that is BUILD_TESTING. If Gentoo wants

Re: Review Request 122206: [kio] Make tests optional

or this seems more reasonable to you guys as well? - Albert Vaca Cintora On Feb. 6, 2015, 4:14 p.m., Andreas Sturmlechner wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122206

Re: Review Request 122913: Added an event() version that takes no icon and will use a default one

and will use a default one depending on the notification type Diffs - src/knotification.h f2dcd74e26a4feefe53dc0e536b0178d5ce287e1 src/knotification.cpp 293de09bae8d16b77df81ee2fe447c3246a476b5 Diff: https://git.reviewboard.kde.org/r/122913/diff/ Testing --- Thanks, Albert Vaca Cintora

Re: Review Request 122913: Added an event() version that takes no icon and will use a default one

293de09bae8d16b77df81ee2fe447c3246a476b5 Diff: https://git.reviewboard.kde.org/r/122913/diff/ Testing --- Thanks, Albert Vaca Cintora ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks

Re: Review Request 122864: Added event() version that takes StandardEvent eventId and QString iconName

when using StandardEvents instead of app-defined events. Diffs - src/knotification.cpp 293de09bae8d16b77df81ee2fe447c3246a476b5 src/knotification.h f2dcd74e26a4feefe53dc0e536b0178d5ce287e1 Diff: https://git.reviewboard.kde.org/r/122864/diff/ Testing --- Thanks, Albert Vaca

Re: Review Request 122864: Added event() version that takes StandardEvent eventId and QString iconName

On mar. 9, 2015, 11:20 a.m., Martin Klapetek wrote: Ship It! Martin Klapetek wrote: Actually wait, StandardEvents should have standard icons, why would you need to change them? Albert Vaca Cintora wrote: They don't have a standard, default icon: you have to specify

Re: Review Request 122900: KPluginSelector to provide initialization arguments for the configuration modules

://git.reviewboard.kde.org/r/122900/#comment53110 @since 5.9 src/kpluginselector.h https://git.reviewboard.kde.org/r/122900/#comment53111 @since 5.9 - Albert Vaca Cintora On mar. 11, 2015, 1:53 a.m., Aleix Pol Gonzalez wrote

Review Request 122913: Added an event() version that takes no icon and will use a default one

://git.reviewboard.kde.org/r/122913/diff/ Testing --- Thanks, Albert Vaca Cintora ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 122913: Added an event() version that takes no icon and will use a default one

/knotification.h f2dcd74e26a4feefe53dc0e536b0178d5ce287e1 src/knotification.cpp 293de09bae8d16b77df81ee2fe447c3246a476b5 Diff: https://git.reviewboard.kde.org/r/122913/diff/ Testing --- Thanks, Albert Vaca Cintora ___ Kde-frameworks-devel mailing list Kde

Re: Review Request 122864: Added event() version that takes StandardEvent eventId and QString iconName

., Albert Vaca Cintora wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122864/ --- (Updated mar. 9, 2015, 6:02 a.m

Review Request 122864: Added event() version that takes StandardEvent eventId and QString iconName

://git.reviewboard.kde.org/r/122864/diff/ Testing --- Thanks, Albert Vaca Cintora ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 112177: Split URL drop functionality from KLineEdit

c17c648 staging/kcompletion/src/klineedit.cpp 213b196 staging/kcompletion/src/klineedit.h e9f3332 staging/kcompletion/src/kcombobox.h 0d4e912 Diff: http://git.reviewboard.kde.org/r/112177/diff/ Testing --- Manual testing + tests passed Thanks, Albert Vaca Cintora

Re: [Kde-hardware-devel] Review Request 111699: Fixed no such signal message in UPowerManager at startup

On July 26, 2013, 12:05 p.m., Lukáš Tinkl wrote: I'm curious why this is needed, after all, your change just uses a different mechanism to connect the signals Albert Vaca Cintora wrote: I'm not sure if the current code actually works, but it gives that error in runtime so I think

Re: [Kde-hardware-devel] Review Request 111699: Fixed no such signal message in UPowerManager at startup

--- Manual testing. Thanks, Albert Vaca Cintora ___ Kde-hardware-devel mailing list Kde-hardware-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-hardware-devel

Re: [Kde-hardware-devel] Review Request 111699: Fixed no such signal message in UPowerManager at startup

. - Albert --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/111699/#review36528 --- On July 25, 2013, 10:36 p.m., Albert Vaca Cintora

Re: Review Request 111184: Url drop functionality in KUrlRequester does not depend on KLineEdit (since we have to port it to QLineEdit)

ba67bdc kdeui/widgets/kcombobox.h ccb019d kdeui/widgets/klineedit.h 7ac22f6 kio/kfile/kurlrequester.cpp fa6b234 Diff: http://git.reviewboard.kde.org/r/84/diff/ Testing --- Thanks, Albert Vaca Cintora ___ Kde-frameworks-devel mailing list

Re: Review Request 111184: Url drop functionality in KUrlRequester does not depend on KLineEdit (since we have to port it to QLineEdit)

--- On June 25, 2013, 10:46 a.m., Albert Vaca Cintora wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/84

Re: Review Request 111184: Url drop functionality in KUrlRequester does not depend on KLineEdit (since we have to port it to QLineEdit)

kdeui/widgets/klineedit.h 7ac22f6 kio/kfile/kurlrequester.cpp fa6b234 Diff: http://git.reviewboard.kde.org/r/84/diff/ Testing --- Thanks, Albert Vaca Cintora ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https

Review Request 111184: Moved url drop functionality from KLineEdit to KUrlChooser

--- Thanks, Albert Vaca Cintora ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 111184: Url drop functionality in KUrlRequester does not depend on KLineEdit (since we have to port it to QLineEdit)

it should be discussed first. (Reviewed by aacid and apol) Diffs - kio/kfile/kurlrequester.cpp fa6b234 Diff: http://git.reviewboard.kde.org/r/84/diff/ Testing --- Thanks, Albert Vaca Cintora ___ Kde-frameworks-devel mailing list

Re: Review Request 110430: [Taskbar applet] Added actions to be perfomed on middle click

, 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

Re: Review Request 110430: [Taskbar applet] Added actions to be perfomed on middle click

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

Review Request 110430: [Taskbar applet] Added actions to be perfomed on middle click

/desktop/applets/tasks/windowtaskitem.cpp f840076 Diff: http://git.reviewboard.kde.org/r/110430/diff/ Testing --- Manual testing. Thanks, Albert Vaca Cintora