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 KNoti

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

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

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

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

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 `${CMAKE_INSTAL

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 t

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 you

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, kde-framework

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?

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, kde-fr

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

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

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

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 make

Re: KDE apps have missing icons when not on Breeze

tals Cid > wrote: > > > > > > El dijous, 16 d’agost de 2018, a les 15:19:36 CEST, Albert Astals Cid > va escriure: > > > > Missatge de Albert Vaca del dia dj., 16 > d’ag. 2018 a > > > > les 13:57: > > > > > > > > > Hi e

Re: KDE apps have missing icons when not on Breeze

/src/kicontheme.cpp#L70 On Wed, Aug 29, 2018 at 12:58 PM Aleix Pol wrote: > > On Tue, Aug 28, 2018 at 10:45 PM Albert Astals Cid wrote: > > > > El dijous, 16 d’agost de 2018, a les 15:19:36 CEST, Albert Astals Cid va > > escriure: > > > Missatge de Albert Vaca de

Re: KDE apps have missing icons when not on Breeze

On Thu, Aug 16, 2018 at 2:41 PM Dominik Haumann wrote: > Just yesterday Kåre worked around a similar issue when running > Kate in Gnome. See fix: https://phabricator.kde.org/D14856 > The solution for Kate solves a more specific problem. If they can't find the icon "games-config-options", then the

KDE apps have missing icons when not on Breeze

Hi everyone, If we want to reach more potential users, we have to make sure KDE apps look properly in every desktop. Take a look at how KDE apps look in Gnome, you will see there are lots of missing icons. https://imgur.com/a/nkeiryb It think it is important to get this fixed, as it can make peo

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 QSt

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 i

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 DETA

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 https://phabricator.kde.org/D6906?vs=17194&id

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 think

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

[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) instea

[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 src/knotific

[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&id=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&id=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 emit

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

albertvaka added a comment. As of now in Plasma, the "default" action will appear as another action button, while in Gnome it will behave as the linked spec says: clicking the notification popup triggers the default action. If this is accepted I will propose a patch for making the notificati

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

albertvaka updated this revision to Diff 10186. albertvaka added a comment. Missing QStringLiteral REPOSITORY R289 KNotifications CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D4142?vs=10185&id=10186 BRANCH master REVISION DETAIL https://phabricator.kde.org/D4142 AFFECTED F

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

albertvaka updated this revision to Diff 10185. albertvaka added a comment. Commited a file by mistake. Still learning how to use arc :) REPOSITORY R289 KNotifications CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D4142?vs=10183&id=10185 BRANCH master REVISION DETAIL https:/

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

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

[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, arrowdodge

[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

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

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

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

Qt5Test Did I miss something 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: > h

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

marked as submitted. Review request for KDE Frameworks and Aleix Pol Gonzalez. Changes --- Submitted with commit dedf55c937f95259121c4985f07345e06dd5b47b by Albert Vaca to branch master. Repository: knotifications Description --- This allows to use icon names instead of QPixmaps

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

marked as submitted. Review request for KDE Frameworks and Martin Klapetek. Changes --- Submitted with commit b368fb958df0ce4cc4128029f5649640f46d1559 by Albert Vaca to branch master. Repository: knotifications Description --- Added an event() version that takes no icon and will

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 122900: KPluginSelector to provide initialization arguments for the configuration modules

tps://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 Go

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

src/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 lis

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

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 122864: Added event() version that takes StandardEvent eventId and QString iconName

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

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

getsaddons/src/CMakeLists.txt 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, A

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

eLists.txt 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 Va

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

eLists.txt 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 Va

Review Request 112177: Split URL drop functionality from KLineEdit

letion/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 Va

Re: Review Request 111539: Move kundoactions and kcheckaccelerators to xmlgui

274915a staging/xmlgui/src/kcheckaccelerators.cpp d448546 staging/xmlgui/src/CMakeLists.txt f7dc624 kdeui/CMakeLists.txt 24b0f1f Diff: http://git.reviewboard.kde.org/r/111539/diff/ Testing --- It builds Thanks, Albert Vaca Cintora ___ Kde

Review Request 111539: Move kundoactions and kcheckaccelerators to xmlgui

d448546 staging/xmlgui/src/CMakeLists.txt f7dc624 kdeui/CMakeLists.txt 24b0f1f Diff: http://git.reviewboard.kde.org/r/111539/diff/ Testing --- It builds Thanks, Albert Vaca Cintora ___ Kde-frameworks-devel mailing list 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)

RTING.html 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 ma

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

Edit? > > It'll be more robust AFAICT. > > Albert Vaca Cintora wrote: > I'm using hasUrls() instead because KUrlMimeData returns a list of urls, > which is more expensive than what Qt does (a string comparison). > > Also, if our way of checking URLs is

Re: QLineEdit and QComboBox tasks

, when we already have KUrlRequester. [1] https://git.reviewboard.kde.org/r/84/ Regards, Albert Vaca On Mon, Jun 24, 2013 at 11:26 AM, Kevin Ottens wrote: > Hello, > > On Saturday 22 June 2013 17:34:41 Albert Vaca wrote: >> There are two tasks in Qt5 Epics [1] to implement repl

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

.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 Kde-frameworks-devel@kde

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

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

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

et because 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 ma

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

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

QLineEdit and QComboBox tasks

KUrlRequester. [1] http://community.kde.org/Frameworks/Epics/Contributions_to_Qt5#Contributing_to_Qt_5_epic [2] https://bugs.kde.org/show_bug.cgi?id=188129 Albert Vaca ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org