Re: Let's reserve F10 and Shift+F10 for accessibility

[Jeremy Whiting]

Great idea. I have always since Windows 95 used shift-f10 for bringing up
context menus. I think many other people may have learned this as well.
It's just habit at this point. F10 for showing/bringing up the menu is also
a great idea. As you pointed out it is used in many places for that
already. I am just learning that now, always used alt myself.

So a big +1 from me.

BR,
Jeremy

On Wed, Sep 6, 2023 at 3:28 AM Felix Ernst  wrote:

> Hi!
>
> While testing the accessibility of Dolphin for visually-impaired people I
> noticed that the menu bar is not part of the normal Tab key focus chain.
> The same seems to be true for all KDE applications I tested. I brought this
> point up with KDE's accessibility group (#kde-accessibility:kde.org) and
> was told that that is normal. Instead, users are supposed to be able to
> open a menu using either the Alt key or the F10 key.
>
> Unfortunately, KDE software doesn't seem to follow that rule either, so
> the only way to focus the menu bar using only a keyboard would be to hold
> down the Alt key, notice the accelerators in the menu bar (i.e. an
> underlined F in File), and then press for example Alt+F to open the File
> menu. Now of course this doesn't work if there is no File menu in the menu
> bar. It also doesn't work if the application uses a hamburger menu instead
> of a menu bar. A blind user won't be able to identify which kind of menu an
> application provides.
>
> We need a consistent way for visually-impaired users to open a menu or
> some users won't be able to use every action our applications offer! The
> way to open a menu should also be consistent with software originating from
> outside of KDE, so a user can open a menu without having to know if it is a
> KDE application or not.
>
> From what I can tell, F10 is the only sensible choice here. F10 to open a
> menu is what many design guidelines seem to already follow:
> - Gnome https://developer.gnome.org/hig/reference/keyboard.html
> - Microsoft
> https://support.microsoft.com/en-gb/windows/keyboard-shortcuts-in-apps-139014e7-177b-d1f3-eb2e-7298b2599a34
> - Chrome
> - Firefox (but Alt also works here)
> - (Web Accessibility Initiative mentions Shift+F10 but not F10
> https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/)
>
> The only other key that even made sense to consider to me was the Alt key,
> but this doesn't seem like a good idea IMO, because:
> - it conflicts with the accelerator (
> https://doc.qt.io/qt-5/accelerators.html) workflow (quickly pressing Alt
> to see if a button has underlined text and can be directly activated)
> - it might lead to accidental activation especially in the context of
> using keyboard shortcuts that also use Alt, but also purely because the key
> is at the bottom of the keyboard.
>
> [1] I propose that we reserve the F10 key in most/all applications to
> either open the first menu in the menu bar or open the hamburger menu
> (depending on application).
>
>
>
> A completely separate issue is the opening of context menus using only a
> keyboard. This functionality is provided by the "Menu" key on some
> keyboards. However, many keyboards – especially in notebooks – do not have
> a menu key. So, we still need to provide a way to open a context menu for
> those. For the same reasons as above, consistency with software originating
> from outside KDE is important here. Shift+F10 seems to be the typical
> shortcut here (Web Accessibility Initiative
> https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/, Firefox,
> Microsoft
> https://support.microsoft.com/en-gb/windows/keyboard-shortcuts-in-apps-139014e7-177b-d1f3-eb2e-7298b2599a34
> ).
>
> [2] I propose that we reserve the Shift+F10 key combination to open the
> context menu for the item that has keyboard focus. It should have the same
> effect as the "Menu" key many keyboards have.
>
>
>
> Please let me know if you agree that these are good ideas or not. Or let
> me know if you think I should start a discussion about this outside a
> mailing list. I currently can't even imagine any good alternative solution
> to these problems, so directly announcing that this is a change I want to
> work on on this mailing list makes the most sense to me for now. Any
> objections?
>
>
> *Implementation*
> This is sort of secondary to the main content of this eMail above, so feel
> free to ignore this section for now if my proposals above will be
> challenged. But I assume that talking about possible ways to implement this
> might help making the above ideas more clear/concrete.
>
> I think proposal [1] (F10 opens menu) will sometimes need to be
> implemented in application code. It might not be clear from outside code
> what can be considered the main menu especially in applications that do not
> have a standard menu bar.
> I currently plan to implement this for all users of KHamburgerMenu at
> once. Pressing F10 would focus/open the menu bar if it is visible or it
> would open the hamburger menu if the menu bar is 

Re: Splitting KGlobalAccel interface and runtime

[Jeremy Whiting]

Nevermind. rebuilt and everything seems to be working for now.

On Mon, Mar 6, 2023 at 10:02 AM Jeremy Whiting  wrote:

> Was something decided about this? I ask because I went and built
> frameworks kf6 over the weekend with kdesrc-build into /usr/local/ with my
> existing arch packages in /usr, etc. and afterwards the kf5 version of
> yakuake can no longer receive keyboard shortcuts (to hide/show, etc.) It's
> entirely possible I messed something up in the process, but thought I'd ask
> here in case kglobalaccel is still up in the air in regards to how it will
> work with kf5 and kf6 applications (or maybe I need to run both
> kglobalaccel5 and kglobalaccell6 or something during transition times?)
>
> thanks,
> Jeremy
>
> On Tue, Feb 14, 2023 at 8:25 AM Aleix Pol  wrote:
>
>> On Tue, Feb 14, 2023 at 10:13 AM Kevin Ottens  wrote:
>> >
>> > Hello,
>> >
>> > On Monday, 13 February 2023 21:25:54 CET Vlad Zahorodnii wrote:
>> > > On 2/13/23 22:05, Nicolas Fella wrote:
>> > > > Hi,
>> > > >
>> > > > the kglobalaccel framework currently contains two pieces:
>> kglobalacceld,
>> > > > the runtime component that manages global shortcuts, and an
>> > > > application-side library to interact with it.
>> > > >
>> > > > The two communicate with each other via DBus. On X11 there is a
>> > > > standalone kglobalacceld5 process providing the interface, on
>> Wayland
>> > > > the runtime is linked into KWin and thus the kwin_wayland process
>> > > > provides the interface.
>> > > >
>> > > > The current architecture has a number of downsides:
>> > > >
>> > > > - Any call to the KGlobalAccel library may DBus-activate the
>> > > > kglobalacceld5 process, which may be undesired on Desktop other than
>> > > > Plasma since it competes with their native shortcut system. We tried
>> > > > fixing that by making such calls no-op on !Plasma, but that broke
>> things
>> > > > for people that did want it to run, for example people using KWin
>> with
>> > > > LXQt, because KWin relies on KGlobalAccel for shortcuts
>> > > >
>> > > > - We want to keep the dependencies of the interface library minimal,
>> > > > which is inconvenient for the development of the runtime part. For
>> > > > example we really want to use KIO::ApplicationLauncherJob in the
>> > > > runtime, but currently can't, because that would introduce a
>> dependency
>> > > > cycle in Frameworks (KIO depends on KXmlGui, which depends on
>> > > > KGlobalAccel, which would depend on KIO)
>> > > >
>> > > > - Coinstallability of KF5 and KF6. Conceptually there can only be
>> one
>> > > > kglobalacceld. If both KF5 KGlobalAccel and KF6 KGlobalAccel
>> install a
>> > > > kglobalacceld this is going to be problematic. This also means that
>> a
>> > > > KF6-based kglobalacceld must work with a KF5 interface library
>> > > >
>> > > > - Other shortcut daemon implementations. Since somewhat recently
>> there
>> > > > is an XDG Portal for global shortcuts. Platforms like Windows and
>> macOS
>> > > > also have ways for applications to register global shortcuts. While
>> we
>> > > > are currently not using any of these it's very well possible that we
>> > > > would eventually want to use the KGlobalAccel interface library to
>> > > > interact with those. Having the kglobalacceld runtime in the same
>> > > > frameworks therefore doesn't feel right.
>> > > >
>> > > > To address these issues I suggest we split out the runtime part of
>> > > > kglobalaccel into its own project, under the Plasma release group,
>> > > > because that's primarily where it's used/supported. The interface
>> > > > library would remain in frameworks. We have a similar situation with
>> > > > activities, where the manager (kactivitymanagerd) is in Plasma and
>> the
>> > > > interface is in Frameworks. When doing this we'd also change the
>> way how
>> > > > kglobalacceld is started away from DBus activation towards
>> explicitly
>> > > > starting it as part of the Plasma startup. This avoids accidentally
>> > > > launching it when it shouldn't be but still allows to explicitly
>> start
>> > > 

Re: Splitting KGlobalAccel interface and runtime

[Jeremy Whiting]

Was something decided about this? I ask because I went and built frameworks
kf6 over the weekend with kdesrc-build into /usr/local/ with my existing
arch packages in /usr, etc. and afterwards the kf5 version of yakuake can
no longer receive keyboard shortcuts (to hide/show, etc.) It's entirely
possible I messed something up in the process, but thought I'd ask here in
case kglobalaccel is still up in the air in regards to how it will work
with kf5 and kf6 applications (or maybe I need to run both kglobalaccel5
and kglobalaccell6 or something during transition times?)

thanks,
Jeremy

On Tue, Feb 14, 2023 at 8:25 AM Aleix Pol  wrote:

> On Tue, Feb 14, 2023 at 10:13 AM Kevin Ottens  wrote:
> >
> > Hello,
> >
> > On Monday, 13 February 2023 21:25:54 CET Vlad Zahorodnii wrote:
> > > On 2/13/23 22:05, Nicolas Fella wrote:
> > > > Hi,
> > > >
> > > > the kglobalaccel framework currently contains two pieces:
> kglobalacceld,
> > > > the runtime component that manages global shortcuts, and an
> > > > application-side library to interact with it.
> > > >
> > > > The two communicate with each other via DBus. On X11 there is a
> > > > standalone kglobalacceld5 process providing the interface, on Wayland
> > > > the runtime is linked into KWin and thus the kwin_wayland process
> > > > provides the interface.
> > > >
> > > > The current architecture has a number of downsides:
> > > >
> > > > - Any call to the KGlobalAccel library may DBus-activate the
> > > > kglobalacceld5 process, which may be undesired on Desktop other than
> > > > Plasma since it competes with their native shortcut system. We tried
> > > > fixing that by making such calls no-op on !Plasma, but that broke
> things
> > > > for people that did want it to run, for example people using KWin
> with
> > > > LXQt, because KWin relies on KGlobalAccel for shortcuts
> > > >
> > > > - We want to keep the dependencies of the interface library minimal,
> > > > which is inconvenient for the development of the runtime part. For
> > > > example we really want to use KIO::ApplicationLauncherJob in the
> > > > runtime, but currently can't, because that would introduce a
> dependency
> > > > cycle in Frameworks (KIO depends on KXmlGui, which depends on
> > > > KGlobalAccel, which would depend on KIO)
> > > >
> > > > - Coinstallability of KF5 and KF6. Conceptually there can only be one
> > > > kglobalacceld. If both KF5 KGlobalAccel and KF6 KGlobalAccel install
> a
> > > > kglobalacceld this is going to be problematic. This also means that a
> > > > KF6-based kglobalacceld must work with a KF5 interface library
> > > >
> > > > - Other shortcut daemon implementations. Since somewhat recently
> there
> > > > is an XDG Portal for global shortcuts. Platforms like Windows and
> macOS
> > > > also have ways for applications to register global shortcuts. While
> we
> > > > are currently not using any of these it's very well possible that we
> > > > would eventually want to use the KGlobalAccel interface library to
> > > > interact with those. Having the kglobalacceld runtime in the same
> > > > frameworks therefore doesn't feel right.
> > > >
> > > > To address these issues I suggest we split out the runtime part of
> > > > kglobalaccel into its own project, under the Plasma release group,
> > > > because that's primarily where it's used/supported. The interface
> > > > library would remain in frameworks. We have a similar situation with
> > > > activities, where the manager (kactivitymanagerd) is in Plasma and
> the
> > > > interface is in Frameworks. When doing this we'd also change the way
> how
> > > > kglobalacceld is started away from DBus activation towards explicitly
> > > > starting it as part of the Plasma startup. This avoids accidentally
> > > > launching it when it shouldn't be but still allows to explicitly
> start
> > > > outside of Plasma if really wanted. It would also allow for greater
> > > > flexibility in the development of the runtime, especially around
> > > > dependency constraints.
> > > >
> > > > It wouldn't automatically solve the coinstallability problem of KF5
> and
> > > > KF6, because a kglobalacceld provided by KF5-KGlobalAccel would still
> > > > conflict with a Plasma-provided kglobalacceld, but it's at least
> > > > conceptually less messy since it's clear that the Plasma-provided one
> > > > would be the preferred one to use.
> > > >
> > > > Thoughts about this?
> > >
> > > +1
> > >
> > > There's one caveat though: given that the library and the runtime parts
> > > will have different release schedules, we will have to be careful about
> > > protocol changes. Perhaps we could borrow a thing or two from
> activities?
> >
> > Or... move both runtime and API on the Plasma side? This way no problem
> of
> > different release schedules and it makes it clear that using it ties you
> to a
> > specific desktop anyway?
> >
> > With a quick grep it looks like most of the users are already shipped
> with
> > Plasma or desktop specific anyway. Granted 

Re: Can we rename gitklient?

[Jeremy Whiting]

I think Kittie is too close to Kitty (a terminal application iirc) so I'd
avoid that one at least.

Just my 2c.

Re: New repo in kdereview: KWeather

[Jeremy Whiting]

Looks like it's got a runtime dependency on kirigami (Maybe that's expected
for plasma-mobile, not sure)

Built it on laptop and got this from cmake:

cmake ..
-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Python3: /usr/bin/python3.10 (found version "3.10.8") found
components: Interpreter
-- Could NOT find ReuseTool (missing: REUSETOOL_EXECUTABLE)
CMake Warning at /usr/share/ECM/modules/ECMCheckOutboundLicense.cmake:86
(message):
 Reuse tool not found, skipping test generation
Call Stack (most recent call first):
 CMakeLists.txt:30 (include)


-- Skipping execution of outbound license tests.
-- Installing in the same prefix as Qt, adopting their path scheme.
-- Setting build type to 'Debug' as none was specified.
-- Looking for __GLIBC__
-- Looking for __GLIBC__ - found
-- Performing Test _OFFT_IS_64BIT
-- Performing Test _OFFT_IS_64BIT - Success
-- Performing Test HAVE_DATE_TIME
-- Performing Test HAVE_DATE_TIME - Success
-- Found KF5Config: /usr/lib64/cmake/KF5Config/KF5ConfigConfig.cmake (found
version "5.99.0")
-- Found KF5Kirigami2:
/usr/lib64/cmake/KF5Kirigami2/KF5Kirigami2Config.cmake (found version
"5.99.0")
-- Found Gettext: /usr/bin/msgmerge (found version "0.21.1")
-- Found KF5I18n: /usr/lib64/cmake/KF5I18n/KF5I18nConfig.cmake (found
version "5.99.0")
-- Found KF5CoreAddons:
/usr/lib64/cmake/KF5CoreAddons/KF5CoreAddonsConfig.cmake (found version
"5.99.0")
-- Found KF5Notifications:
/usr/lib64/cmake/KF5Notifications/KF5NotificationsConfig.cmake (found
version "5.99.0")
-- Found KF5: success (found suitable version "5.99.0", minimum required is
"5.90.0") found components: Config Kirigami2 I18n CoreAddons Notifications
-- Found X11: /usr/include
-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so
-- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so -
found
-- Looking for gethostbyname
-- Looking for gethostbyname - found
-- Looking for connect
-- Looking for connect - found
-- Looking for remove
-- Looking for remove - found
-- Looking for shmat
-- Looking for shmat - found
-- Looking for IceConnectionNumber in ICE
-- Looking for IceConnectionNumber in ICE - found
-- Found KF5Plasma: /usr/lib64/cmake/KF5Plasma/KF5PlasmaConfig.cmake (found
version "5.99.0")
-- Found KF5: success (found suitable version "5.99.0", minimum required is
"5.90.0") found components: Plasma
-- Found org.kde.kholidays-QMLModule: TRUE (found version "")
-- The following RUNTIME packages have been found:

* org.kde.kholidays-QMLModule, QML module 'org.kde.kholidays' is a runtime
dependency.

-- The following OPTIONAL packages have been found:

* Python3
  Required to run tests of module ECMCheckOutboundLicense
* Qt5QuickCompiler
* KF5Package (required version >= 5.99.0)
* KF5Service (required version >= 5.99.0)
* Freetype
* PkgConfig
* Fontconfig

-- The following REQUIRED packages have been found:

* ECM (required version >= 5.90.0)
* Qt5Network (required version >= 5.15.7)
* Qt5QmlModels (required version >= 5.15.7)
* Qt5Quick
* Qt5Test
* Qt5Svg
* Qt5QuickControls2
* Qt5Charts
* KF5Kirigami2 (required version >= 5.90.0)
* Gettext
* KF5I18n (required version >= 5.90.0)
* KF5Notifications (required version >= 5.90.0)
* KF5KWeatherCore (required version >= 0.6.0)
* KF5CoreAddons (required version >= 5.99.0)
* Qt5Gui (required version >= 5.15.2)
* Qt5Widgets (required version >= 5.15.2)
* KF5Plasma (required version >= 5.90.0)
* KF5 (required version >= 5.90.0)
* Qt5Qml
* Qt5Core
* Qt5

-- The following features have been disabled:

* SPDX_LICENSE_TESTING, Automatic license testing based on SPDX definitions
(requires reuse tool)

-- The following OPTIONAL packages have not been found:

* ReuseTool
  Required to run tests of module ECMCheckOutboundLicense

-- Configuring done
-- Generating done
-- Build files have been written to:
/home/jeremy/data/devel/kde/src/kde/plasma-mobile/kweather/build

then it built and installed fine, but trying to run failed with this:

kweather
QQmlApplicationEngine failed to load component
qrc:/qml/main.qml:163:26: Type SettingsDialog unavailable
qrc:/qml/settings/SettingsDialog.qml:33:22: Type SettingsComponent
unavailable
qrc:/qml/settings/SettingsComponent.qml:13:1: module
"org.kde.kirigamiaddons.labs.mobileform" is not installed

maybe cmake should have said it depends on kirigami?

On Wed, Nov 9, 2022 at 3:00 PM Devin  wrote:

> Hi everyone,
>
> I would like to put kweather through kdereview:
>
> https://invent.kde.org/plasma-mobile/kweather
>
> KWeather is an application that can give simple weather 

Re: New repo in kdereview: KWeather

[Jeremy Whiting]

After installing kirigami-addons it runs fine, adding my location went
smooth, etc. Only nitpick I found as a user was that it's a bit weird that
Settings -> About changes the main window instead of showing about data in
the little settings window. I would suggest making About be one of the
buttons on the main window, or showing the about data in the settings
window.

On Wed, Nov 9, 2022 at 3:31 PM Jeremy Whiting 
wrote:

> Looks like it's got a runtime dependency on kirigami (Maybe that's
> expected for plasma-mobile, not sure)
>
> Built it on laptop and got this from cmake:
>
> cmake ..
> -- The C compiler identification is GNU 12.2.0
> -- The CXX compiler identification is GNU 12.2.0
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc - skipped
> -- Detecting C compile features
> -- Detecting C compile features - done
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working CXX compiler: /usr/bin/c++ - skipped
> -- Detecting CXX compile features
> -- Detecting CXX compile features - done
> -- Found Python3: /usr/bin/python3.10 (found version "3.10.8") found
> components: Interpreter
> -- Could NOT find ReuseTool (missing: REUSETOOL_EXECUTABLE)
> CMake Warning at /usr/share/ECM/modules/ECMCheckOutboundLicense.cmake:86
> (message):
>  Reuse tool not found, skipping test generation
> Call Stack (most recent call first):
>  CMakeLists.txt:30 (include)
>
>
> -- Skipping execution of outbound license tests.
> -- Installing in the same prefix as Qt, adopting their path scheme.
> -- Setting build type to 'Debug' as none was specified.
> -- Looking for __GLIBC__
> -- Looking for __GLIBC__ - found
> -- Performing Test _OFFT_IS_64BIT
> -- Performing Test _OFFT_IS_64BIT - Success
> -- Performing Test HAVE_DATE_TIME
> -- Performing Test HAVE_DATE_TIME - Success
> -- Found KF5Config: /usr/lib64/cmake/KF5Config/KF5ConfigConfig.cmake
> (found version "5.99.0")
> -- Found KF5Kirigami2:
> /usr/lib64/cmake/KF5Kirigami2/KF5Kirigami2Config.cmake (found version
> "5.99.0")
> -- Found Gettext: /usr/bin/msgmerge (found version "0.21.1")
> -- Found KF5I18n: /usr/lib64/cmake/KF5I18n/KF5I18nConfig.cmake (found
> version "5.99.0")
> -- Found KF5CoreAddons:
> /usr/lib64/cmake/KF5CoreAddons/KF5CoreAddonsConfig.cmake (found version
> "5.99.0")
> -- Found KF5Notifications:
> /usr/lib64/cmake/KF5Notifications/KF5NotificationsConfig.cmake (found
> version "5.99.0")
> -- Found KF5: success (found suitable version "5.99.0", minimum required
> is "5.90.0") found components: Config Kirigami2 I18n CoreAddons
> Notifications
> -- Found X11: /usr/include
> -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so
> -- Looking for XOpenDisplay in /usr/lib/libX11.so;/usr/lib/libXext.so -
> found
> -- Looking for gethostbyname
> -- Looking for gethostbyname - found
> -- Looking for connect
> -- Looking for connect - found
> -- Looking for remove
> -- Looking for remove - found
> -- Looking for shmat
> -- Looking for shmat - found
> -- Looking for IceConnectionNumber in ICE
> -- Looking for IceConnectionNumber in ICE - found
> -- Found KF5Plasma: /usr/lib64/cmake/KF5Plasma/KF5PlasmaConfig.cmake
> (found version "5.99.0")
> -- Found KF5: success (found suitable version "5.99.0", minimum required
> is "5.90.0") found components: Plasma
> -- Found org.kde.kholidays-QMLModule: TRUE (found version "")
> -- The following RUNTIME packages have been found:
>
> * org.kde.kholidays-QMLModule, QML module 'org.kde.kholidays' is a runtime
> dependency.
>
> -- The following OPTIONAL packages have been found:
>
> * Python3
>   Required to run tests of module ECMCheckOutboundLicense
> * Qt5QuickCompiler
> * KF5Package (required version >= 5.99.0)
> * KF5Service (required version >= 5.99.0)
> * Freetype
> * PkgConfig
> * Fontconfig
>
> -- The following REQUIRED packages have been found:
>
> * ECM (required version >= 5.90.0)
> * Qt5Network (required version >= 5.15.7)
> * Qt5QmlModels (required version >= 5.15.7)
> * Qt5Quick
> * Qt5Test
> * Qt5Svg
> * Qt5QuickControls2
> * Qt5Charts
> * KF5Kirigami2 (required version >= 5.90.0)
> * Gettext
> * KF5I18n (required version >= 5.90.0)
> * KF5Notifications (required version >= 5.90.0)
> * KF5KWeatherCore (required version >= 0.6.0)
> * KF5CoreAddons (required version >= 5.99.0)
> * Qt5Gui (required version >= 5.15.2)
> * Qt5Widgets (required version >= 5.15.2)
> * KF5Plasma (required version >= 5.90.

Re: New releases for bugfixes

[Jeremy Whiting]

On Thu, Sep 8, 2022 at 12:51 PM samuel ammonius 
wrote:

> Bug fixes don't change the entire package, only the executable, so
> why can't apps just be programmed to update themselves? There
> could be precompiled binaries stored on the git repos of each project
> for a few CPU architectures, or maybe the app could even recompile
> itself inside /tmp since most systems KDE runs on come with a compiler
> by default (and macros could also be stored so that apps have the
> same configuration throughout updates).
>

That depends entirely on whether the fix was in the executable or a library
that it links to. If a library we can't be
updating libraries willy nilly on user devices. Plus think about how it was
built, which use flags in gentoo, which
compile flags, etc. Which distribution specific patches were applied. Once
you take all that into account there are many
many ways to build kde applications.

>
> Cheers,
> Sam
>
> On Thu, Sep 8, 2022 at 11:58 AM Heiko Becker  wrote:
>
>> On Thursday, 8 September 2022 13:59:43 CEST, Ahmad Samir wrote:
>> > From the git-archive manual page:
>> >
>> > «git archive behaves differently when given a tree ID versus
>> > when given a commit ID or tag ID. In the first case the current
>> > time is used as the modification time of each file in the
>> > archive. In the latter case the commit time as recorded in the
>> > referenced commit object is used instead. Additionally the
>> > commit ID is stored in a global extended pax header if the tar
>> > format is used; it can be extracted using git get-tar-commit-id.
>> > In ZIP files it is stored as a file comment.»
>>
>> Before anybody tries that *now*, at least for Gear the tarballs are
>> currently created with git archive --remote=kde:$repo $branch ..
>> So they currently won't have that information.
>>
>> Regards,
>> Heiko
>>
>>

Re: Incubating app (Git Klient)

[Jeremy Whiting]

Tried to send this earlier, but used the wrong address, so it got stuck in
moderation possibly:

A sponsor is a KDE developer who will walk you through getting a developer
account, getting code reviewed, going over the different release
mechanisms, etc. to decide how best to become an official application.

On Mon, Aug 22, 2022 at 3:20 PM samuel ammonius 
wrote:

> From my current understanding, a sponsor is a KDE developer who works with
> KDE's GitLab managers to make a new repo for your project and make you a
> KDE developer.
>
> On Mon, Aug 22, 2022 at 5:14 PM Hamed Masafi 
> wrote:
>
>> What is a sponsor and what does it do?
>>
>> On Mon, Aug 22, 2022, 21:00 Harald Sitter  wrote:
>>
>>> Heya,
>>>
>>> You'll need a sponsor https://community.kde.org/Incubator ... not me.
>>> I'm lazy :)
>>>
>>> On Sun, Aug 21, 2022 at 11:01 AM Hamed Masafi 
>>> wrote:
>>> >
>>> >
>>> > Hello
>>> > As a longtime kde fan(since 3.4), I would love to contribute to this
>>> group.
>>> > I am developing a graphical client application for git. I think it is
>>> a good option to enter the world of kde.
>>> >
>>> > Features of this program:
>>> >   - The icon displays the files in the Gate folder according to their
>>> status in Dolphin.
>>> >   - For easier access to the right-click menu of files and folders,
>>> options such as pull, push, delete, ignore, etc. have been added.
>>> >   - Graph display of commits.
>>> >   - General Git operations such as pull, push, fetch.
>>> >   - Show branches and distance of commits from the reference branch.
>>> >   - View files and file contents in each branch or commit.
>>> >   - Compare files, folders, branches and commits in a graphical
>>> environment.
>>> >   - Merge conflicting files in git.
>>> >   - Management of remotes, tags.
>>> >   - Auto-completion when writing a commit message.
>>> >   - Markdown editor (written but not yet added to the main program)
>>> >   - And some extra features.
>>> >
>>> > The source is available here:
>>> > https://github.com/HamedMasafi/GitKlient
>>> >
>>> > Currently, only I (Hamid Masafi) am working on the project.
>>> > This project is currently on GitHub, but it can be moved to any other
>>> repository if approved by you.
>>> >
>>> > Please take a look at this repository and let me know what you think.
>>> I look forward to hearing from you.
>>> >
>>> > Best regards
>>> > Hamed Masafi
>>>
>>

Re: Incubating app (Git Klient)

[Jeremy Whiting]

A sponsor is a KDE developer who will walk you through getting a developer
account, getting code reviewed, going over the different release
mechanisms, etc. to decide how best to become an official application.

On Mon, Aug 22, 2022 at 1:44 PM Hamed Masafi  wrote:

> What is a sponsor and what does it do?
>
> On Mon, Aug 22, 2022, 21:00 Harald Sitter  wrote:
>
>> Heya,
>>
>> You'll need a sponsor https://community.kde.org/Incubator ... not me.
>> I'm lazy :)
>>
>> On Sun, Aug 21, 2022 at 11:01 AM Hamed Masafi 
>> wrote:
>> >
>> >
>> > Hello
>> > As a longtime kde fan(since 3.4), I would love to contribute to this
>> group.
>> > I am developing a graphical client application for git. I think it is a
>> good option to enter the world of kde.
>> >
>> > Features of this program:
>> >   - The icon displays the files in the Gate folder according to their
>> status in Dolphin.
>> >   - For easier access to the right-click menu of files and folders,
>> options such as pull, push, delete, ignore, etc. have been added.
>> >   - Graph display of commits.
>> >   - General Git operations such as pull, push, fetch.
>> >   - Show branches and distance of commits from the reference branch.
>> >   - View files and file contents in each branch or commit.
>> >   - Compare files, folders, branches and commits in a graphical
>> environment.
>> >   - Merge conflicting files in git.
>> >   - Management of remotes, tags.
>> >   - Auto-completion when writing a commit message.
>> >   - Markdown editor (written but not yet added to the main program)
>> >   - And some extra features.
>> >
>> > The source is available here:
>> > https://github.com/HamedMasafi/GitKlient
>> >
>> > Currently, only I (Hamid Masafi) am working on the project.
>> > This project is currently on GitHub, but it can be moved to any other
>> repository if approved by you.
>> >
>> > Please take a look at this repository and let me know what you think. I
>> look forward to hearing from you.
>> >
>> > Best regards
>> > Hamed Masafi
>>
>

Re: MacOS signing issue.

[Jeremy Whiting]

Notarizing and signing are actually separate things on MacOS, signing the
app or checking the signature of the dmg are orthogonal to the issue
described and the popup in that report. Notarization is sending the app
(zipped) to apple's notarization service so they can check it doesn't use
any apis that it shouldn't or something, then the .app needs to be
"stapled" with the notarization before putting it into the dmg. That said
iirc signing the app is a requirement before submitting the app to apple's
notarization service in the first place.

On Thu, Oct 22, 2020 at 11:12 AM Ben Cooksley  wrote:

> On Fri, Oct 23, 2020 at 6:08 AM Michael Reeves 
> wrote:
>
>> Could someone familiar with the CI and OS X signing machinism look at
>> this.
>>
>> https://bugs.kde.org/show_bug.cgi?id=428062
>>
>> I have no way to test or fix this issue. Which as far as I know is an
>> issue with the CI on binary factory.
>>
>
> This is because Craft to my knowledge at this time does not support
> notarization of MacOS binaries.
>
> Once that has been added, the issue should disappear.
>
> Regards,
> Ben
>

Re: MacOS signing issue.

[Jeremy Whiting]

Notarizing and signing are actually separate things on MacOS, signing the
app or checking the signature of the dmg are orthogonal to the issue
described and the popup in that report. Notarization is sending the app
(zipped) to apple's notarization service so they can check it doesn't use
any apis that it shouldn't or something, then the .app needs to be
"stapled" with the notarization before putting it into the dmg. That said
iirc signing the app is a requirement before submitting the app to apple's
notarization service in the first place.

On Thu, Oct 22, 2020 at 11:12 AM Ben Cooksley  wrote:

> On Fri, Oct 23, 2020 at 6:08 AM Michael Reeves 
> wrote:
>
>> Could someone familiar with the CI and OS X signing machinism look at
>> this.
>>
>> https://bugs.kde.org/show_bug.cgi?id=428062
>>
>> I have no way to test or fix this issue. Which as far as I know is an
>> issue with the CI on binary factory.
>>
>
> This is because Craft to my knowledge at this time does not support
> notarization of MacOS binaries.
>
> Once that has been added, the issue should disappear.
>
> Regards,
> Ben
>

Re: KDE Applications discussion

[Jeremy Whiting]

Thanks for pointing that out. Interesting discussion.

On Wed, May 8, 2019 at 11:19 AM Jonathan Riddell  wrote:

> There is a discussion about KDE Applications process happening on an
> untagged Phab work item
>
> https://phabricator.kde.org/T10812
>
> Jonathan
>
>

D15481: Fix 'Impossible to use knsrc file for uploads from non standard location'

[Jeremy Whiting]

whiting accepted this revision.
whiting added a comment.
This revision is now accepted and ready to land.


  Looks good to me. Thanks for doing that fix.

REPOSITORY
  R304 KNewStuff

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D15481

To: habacker, whiting
Cc: whiting, kde-frameworks-devel, michaelh, ngraham, bruns

D7968: Forward QComboBox signals instead of QComboBox lineedit signals

[Jeremy Whiting]

whiting added a comment.


  Hey all, this change breaks Kompare 
https://bugs.kde.org/show_bug.cgi?id=390024 which watches a KUrlRequester's 
textChanged signal to update a button's enabled state. We are not seeing the 
textChanged signal on the KUrlRequester anymore when programatically setting 
the url with the KUrlComboBox we give to the KUrlRequester via it's setUrl 
method. Looking at KUrlComboBox::setUrl it's blocking signals in the body of 
setUrl and since we are not connecting to the QLineEdit anymore we never get 
that signal.

REPOSITORY
  R241 KIO

REVISION DETAIL
  https://phabricator.kde.org/D7968

To: mwolff, apol, dfaure
Cc: whiting, #frameworks, michaelh

Re: Merging KMag frameworks branch to master

[Jeremy Whiting]

Hi Ben,

It looks like that wont be needed actually. I had moved it to phabricator,
just with a non obvious name. Here's my irc log:

[Tuesday, September 1, 2015] [5:54:21 PM MDT]kdepepo: is
kaccessible needed for kmag (or anything else) in Qt5/kf5 setup ?
[Tuesday, September 1, 2015] [5:54:49 PM MDT]and what's the
state of the kmag frameworks branch? is it "done" just needs merging or are
there issues to fix still ?
[Tuesday, September 1, 2015] [5:57:32 PM MDT]  jpwhiting, not sure
about kaccessible ... as far as I know, kmag links to qaccessibleclient,
which is a lib in playground
[Tuesday, September 1, 2015] [5:58:56 PM MDT]  issues:
https://paste.kde.org/pgvbptjnd
[Tuesday, September 1, 2015] [6:10:35 PM MDT]hmm? which X11
includes are missing for kmousetool ?
[Tuesday, September 1, 2015] [6:10:42 PM MDT]I built it here
last week, /me looks
[Tuesday, September 1, 2015] [6:11:42 PM MDT]kdepepo: ^^
[Tuesday, September 1, 2015] [6:12:22 PM MDT]  I don't remember
exactly, but I think shumski complained
[Tuesday, September 1, 2015] [6:12:45 PM MDT]k, I'll ask him
[Tuesday, September 1, 2015] [6:12:47 PM MDT]thanks
[Tuesday, September 1, 2015] [6:15:23 PM MDT]  jpwhiting, looking
at my changes, I have a find_package(X11) there, but nothing which adds the
X11 include dirs to the include path.
[Tuesday, September 1, 2015] [6:16:22 PM MDT] 
  target_link_libraries should be adding include paths now iirc
[Tuesday, September 1, 2015] [6:16:37 PM MDT]  hm, and it actually
only needs libXtst, not X11 ... not sure if the cmake stuff is correct
[Tuesday, September 1, 2015] [6:17:18 PM MDT]ah, probably
doesn't need all of the ${X11_LIBRARIES} then?
[Tuesday, September 1, 2015] [7:21:55 PM MDT]kdepepo: I'm
beginning to think that either a todo.kde.org or a workboard on phabricator
would be good to track what is left to d
o re porting to Qt5/kf5
[Tuesday, September 1, 2015] [7:22:19 PM MDT] 
http://developer.kde.org/~cfeck/portingstatus.html is good, but only shows
what's been merged/committed, not what's in progress a
nd by whom
[Friday, September 4, 2015] [2:15:52 PM MDT] removing the
fixx11 include compiles without errors.
[Friday, September 4, 2015] [2:16:00 PM MDT] ok, ship it! :)
[Friday, September 4, 2015] [2:17:24 PM MDT]^Bkmousetool^B
^C5(frameworks)^C ^C12v15.04.1-10-gac639c4^C * ^C3Christoph Feck^C:
kmousetool/kmousetool.cpp
[Friday, September 4, 2015] [2:17:24 PM MDT]Remove obsolete
#include 
[Friday, September 4, 2015] [2:17:25 PM MDT] 
http://commits.kde.org/kmousetool/ac639c429b209bb95beb0d3c79ffa18cc470b452
[Friday, September 4, 2015] [2:18:09 PM MDT] Quit   pursuivant
(pursuivant@kde/bot/commit-notifications) has left this server (Quit:
transmission timeout).
[Friday, September 4, 2015] [2:18:33 PM MDT] I haven't had
time yet to check how the reverse AA scaler can be added to kmag.
[Friday, September 4, 2015] [2:19:02 PM MDT] Currently it
simply zooms by setting a scale matrix.
[Friday, September 4, 2015] [2:19:15 PM MDT] I suggest we
add it to the kmag TODO file if it has one, but I don't think that should
block frameworks getting merged to master
[Friday, September 4, 2015] [2:19:16 PM MDT] imo
[Friday, September 4, 2015] [2:19:40 PM MDT] right, what I
posted was my todo list :P
[Friday, September 4, 2015] [2:19:44 PM MDT] ah, ok
[Friday, September 4, 2015] [2:20:07 PM MDT] I started
putting your todo list on https://phabricator.kde.org/tag/qt_5_porting/ :)
[Friday, September 4, 2015] [2:21:18 PM MDT] kmag mode not
saved is bug 332303
[Friday, September 4, 2015] [2:24:40 PM MDT] k, added

So tldr the list is alive here:
https://phabricator.kde.org/tag/qt_5_porting/

thanks,
Jeremy

On Mon, Mar 6, 2017 at 11:45 PM, Ben Cooksley <bcooks...@kde.org> wrote:

> On Tue, Mar 7, 2017 at 4:19 PM, Jeremy Whiting <jpwhit...@kde.org> wrote:
> > It looks like todo.kde.org is down or no longer a thing. I thought I
> moved
> > the list to phabricator, but can't seem to find it on there either.
>
> Hi Jeremy,
>
> todo.kde.org was phased out a while back after a notified period for
> migrations.
> Sysadmin have since archived the site in long term storage.
>
> If necessary we can probably bring it online temporarily in order for
> a migration to Phabricator to be made for these tasks.
> Please file a Sysadmin task if we need to do that.
>
> Cheers,
> Ben
>
> >
> > On Mon, Mar 6, 2017 at 2:56 PM, Albert Astals Cid <aa...@kde.org> wrote:
> >>
> >> El dilluns, 6 de març de 2017, a les 1:29:32 CET, Christoph Feck va
> >> escriure:
> >> > On 05.03.2017 23:59, Albert Astals Cid wrote:
> >> > > I had a quick look and features seem to work as good/bad in the
> >> > > frameworks
> >> > > branch as in master.
> >> > >
> >> 

Re: Merging KMag frameworks branch to master

[Jeremy Whiting]

It looks like todo.kde.org is down or no longer a thing. I thought I moved
the list to phabricator, but can't seem to find it on there either.

On Mon, Mar 6, 2017 at 2:56 PM, Albert Astals Cid <aa...@kde.org> wrote:

> El dilluns, 6 de març de 2017, a les 1:29:32 CET, Christoph Feck va
> escriure:
> > On 05.03.2017 23:59, Albert Astals Cid wrote:
> > > I had a quick look and features seem to work as good/bad in the
> frameworks
> > > branch as in master.
> > >
> > > If noone disagrees I'll do the merge on March 13th.
> >
> > Jeremy Whiting had a list somewhere on todo.kde.org with tasks that
> > blocked merging. I only remember two, because I was responsible for
> > them, but I think there were more.
>
> Does anyone have a link to that list? Wouldn't want to force a merge that's
> not ready :)
>
> Cheers,
>   Albert
>
> >
> > First, I did not correctly port the saving to remote image via KIO.
> > Someone familiar with KIO could look at
> > https://cgit.kde.org/kmag.git/commit/?h=frameworks=
> daa05153573ace5bb76479
> > 71a7a21dc724777a4f and correct it.
> >
> > Second,
> > https://cgit.kde.org/kmag.git/commit/?h=frameworks=
> 1f8e4208d72c7f9ce6fa73
> > 9f477151aab1fadccf enabled building against QAccessibilityClient, but I
> > could not test it.
>
>
>

Re: Merging KMag frameworks branch to master

[Jeremy Whiting]

I agree. I think the only remaining issues were "nice-to-have" features
that can be developed after it has been merged to master.

On Sun, Mar 5, 2017 at 3:59 PM, Albert Astals Cid  wrote:

> I had a quick look and features seem to work as good/bad in the frameworks
> branch as in master.
>
> If noone disagrees I'll do the merge on March 13th.
>
> Cheers,
>   Albert
>

Re: Review Request 121584: Make the webapp manager run again.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/121584/
---

(Updated Feb. 8, 2017, 1:25 p.m.)


Status
--

This change has been discarded.


Review request for Bodega, kdelibs, Aaron J. Seigo, and Marco Martin.


Repository: bodega-webapp-manager


Description
---

Make the webapp manager run again.


Diffs
-

  app.js ceede62c192451f2ac2bba8848a97f9bcc4a2f4a 
  package.json 715d01c3fa9e9f3a890ee9e047093fdfb528095f 
  public/favicon.ico PRE-CREATION 
  routes.js 891660f7fb3d036b5907114c58bd17f1128b1efe 
  views/layout.jade 423a37493acac482369693168cce32886a71f0bb 

Diff: https://git.reviewboard.kde.org/r/121584/diff/


Testing
---

It runs now, and gives 200 or 304 responses, though the browser currently shows 
"Page Not Found"


Thanks,

Jeremy Whiting

Re: Review Request 128814: Add Qt5Network as a public dependency.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128814/#review98825
---


Ship it!




Ship It!

- Jeremy Whiting


On Sept. 1, 2016, 11:58 a.m., Michael Palimaka wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128814/
> ---
> 
> (Updated Sept. 1, 2016, 11:58 a.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: attica
> 
> 
> Description
> ---
> 
> Attica uses Qt5Network in its public API, so it must declare it as a public
> dependency otherwise consumers could fail to build if Qt5Network is not 
> already
> found elsewhere in the dependency tree.
> 
> 
> Diffs
> -
> 
>   KF5AtticaConfig.cmake.in 078d03c416316fc446b40405cb35f23665f5ed86 
> 
> Diff: https://git.reviewboard.kde.org/r/128814/diff/
> 
> 
> Testing
> ---
> 
> Consider this test case:
> 
> ```cmake
> project(test)
> find_package(ECM 1.7.0 REQUIRED NO_MODULE)
> find_package(KF5Attica REQUIRED)
> 
> set(test_SRCS test.cpp)
> add_executable(test ${test_SRCS})
> target_link_libraries(test KF5::Attica)
> ```
> 
> Before the change it fails to build with ``ld: cannot find -lQt5::Network``, 
> after the change it passes.
> 
> 
> Thanks,
> 
> Michael Palimaka
> 
>

Re: Review Request 128740: uncompress archives in subfolders

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128740/#review98570
---


Ship it!




Ship It!

- Jeremy Whiting


On Aug. 23, 2016, 8:43 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128740/
> ---
> 
> (Updated Aug. 23, 2016, 8:43 a.m.)
> 
> 
> Review request for KDE Frameworks, Sebastian Kügler and Jeremy Whiting.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> if the archive downloaded by ghns has more than a file inside (either single 
> file or a folder at the root), uncompress it in a folder called the same as 
> the file name (without path or extension)
> 
> this fixes downloading and installing plasma wallpaper packages (those that 
> provide multiple resolutions).
> I don't know if this behavior would in turn break other applications, but i 
> don't think so as it seems the behavior changed between kde4 and kf5.
> if needed i can make it do this only in the case of wallpapers (if 
> (standardResourceDirectory == QLatin1String("wallpaper"))) but i think this 
> should be the correct behavior
> 
> 
> Diffs
> -
> 
>   src/core/installation.cpp a027418 
> 
> Diff: https://git.reviewboard.kde.org/r/128740/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

Re: Review Request 128219: No longer allow installing to generic data folder because of security hole.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128219/
---

(Updated Aug. 15, 2016, 9:49 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks, David Faure and Richard Moore.


Changes
---

Submitted with commit 9746ff5553db0f3e869b0a9970e1304554e6f7fe by Jeremy 
Whiting to branch master.


Repository: knewstuff


Description
---

When an application uses TargetDir=/ or StandardResource=data give a warning on 
the terminal and don't use the chosen location.


Diffs
-

  src/core/installation.cpp a027418 

Diff: https://git.reviewboard.kde.org/r/128219/diff/


Testing
---

No testing done yet, will write a unit test of some kind if this is the right 
direction.


Thanks,

Jeremy Whiting

Re: Review Request 128219: No longer allow installing to generic data folder because of security hole.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128219/
---

(Updated Aug. 12, 2016, 12:58 p.m.)


Review request for KDE Frameworks, David Faure and Richard Moore.


Changes
---

Removed StandardResource "data" altogether since it's not used anymore.


Repository: knewstuff


Description
---

When an application uses TargetDir=/ or StandardResource=data give a warning on 
the terminal and don't use the chosen location.


Diffs (updated)
-

  src/core/installation.cpp a027418 

Diff: https://git.reviewboard.kde.org/r/128219/diff/


Testing
---

No testing done yet, will write a unit test of some kind if this is the right 
direction.


Thanks,

Jeremy Whiting

Re: Review Request 128451: KNewFileMenu: fix creating symlinks with a relative target.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128451/#review97731
---


Ship it!




Ship It!

- Jeremy Whiting


On July 21, 2016, 3:30 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128451/
> ---
> 
> (Updated July 21, 2016, 3:30 p.m.)
> 
> 
> Review request for KDE Frameworks, Chinmoy Ranjan Pradhan and Jeremy Whiting.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> KNameAndUrlInputDialog::url() makes URLs absolute (which is useful in
> general, for e.g. passing to KIO), so I added urlText() to retrieve
> the text as is.
> 
> This removes all the code about showing an error on remote URLs; we just
> create symlinks to the requested target, whether it looks like "../foo" or
> "a:/b" which could be a relative path too (although an unusual one).
> 
> Bug misreported as a comment in bug 352927.
> 
> 
> Diffs
> -
> 
>   src/filewidgets/knameandurlinputdialog.h 
> c32745d02a1a7361ac35a836cf57d7b9952cc49f 
>   src/filewidgets/knameandurlinputdialog.cpp 
> b7a6645874673e998e05ee73a2daef746ce39dd6 
>   src/filewidgets/knewfilemenu.cpp 2e613b19a98587c9a62c9cccf0f8695730798e89 
> 
> Diff: https://git.reviewboard.kde.org/r/128451/diff/
> 
> 
> Testing
> ---
> 
> Created a symlink to "../anotherdir" in konqueror/dolphinpart using "Create 
> New" / "Basic link to file or directory...", the target now stays relative.
> 
> I looked up who wrote that symlink creation code in order to add him as a 
> reviewer  turns out the author of commit 8684162 in kde-baseapps is  
> me.
> 
> 
> Thanks,
> 
> David Faure
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128494: KPropertiesDialog: simplify button box usage, fix behavior on Esc

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128494/#review97728
---


Ship it!




Ship It!

- Jeremy Whiting


On July 21, 2016, 3:06 p.m., David Faure wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128494/
> ---
> 
> (Updated July 21, 2016, 3:06 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kio
> 
> 
> Description
> ---
> 
> slotCancel() isn't called when pressing Esc or closing the window with
> the window manager button.
> 
> Doing this the more standard way (reimplementing accept() and reject())
> simplifies the code (since KPageDialog sets up the buttonbox this way already)
> and will be useful for knewfilemenutest which calls accept() on all types of 
> dialog.
> 
> 
> Diffs
> -
> 
>   src/widgets/kpropertiesdialog.h b451a6ffcb248beb324ef612a0336148c96bccc2 
>   src/widgets/kpropertiesdialog.cpp 808765c706ded7f109719bb2d731692fca0163d8 
>   tests/kpropertiesdialogtest.cpp 7b180608716fa7de0bb2e5221330d0be958ef945 
> 
> Diff: https://git.reviewboard.kde.org/r/128494/diff/
> 
> 
> Testing
> ---
> 
> Looking at the output from kpropertiesdialogtest, to ensure the signals are 
> emitted, and only once.
> Tested OK, Cancel, Esc, Alt+F4.
> 
> 
> Thanks,
> 
> David Faure
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128219: No longer allow installing to generic data folder because of security hole.

[Jeremy Whiting]

> On June 17, 2016, 1:36 a.m., David Faure wrote:
> > src/core/installation.cpp, line 379
> > <https://git.reviewboard.kde.org/r/128219/diff/1/?file=469097#file469097line379>
> >
> > There are of course other values for targetDirectory which would create 
> > problems.
> > - "//"
> > - "./"
> > - "../etc"
> > - and so on
> > 
> > But this is a setting written by the app developer, not by the person 
> > uploading knewstuff data, so we can assume no malicious intention, right?
> 
> Jeremy Whiting wrote:
> Yes only application developer. Or end user if they want to tweak the 
> .knsrc files by hand to introduce a security vulnerability. Though if they 
> wanted to do that there are much easier ways to do it.

Heh, the apidocs for KNS3::DownloadDialog about knsrc files says: 
"StandardResource: not available in KF5, use XdgTargetDir instead." maybe we 
should remove all support for StandardResource=. Though some applications have 
StandardResource=tmp that I saw, are those all broken? or where did the text in 
the apidocs come from? Git blame just says it's from before the split into 
separate git repos.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128219/#review96621
---


On June 16, 2016, 7:55 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128219/
> ---
> 
> (Updated June 16, 2016, 7:55 p.m.)
> 
> 
> Review request for KDE Frameworks, David Faure and Richard Moore.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> When an application uses TargetDir=/ or StandardResource=data give a warning 
> on the terminal and don't use the chosen location.
> 
> 
> Diffs
> -
> 
>   src/core/installation.cpp cbd0653 
> 
> Diff: https://git.reviewboard.kde.org/r/128219/diff/
> 
> 
> Testing
> ---
> 
> No testing done yet, will write a unit test of some kind if this is the right 
> direction.
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128317: Make the download dialog fail when *all* categories are missing, not just one

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128317/#review96956
---


Ship it!




Ship It!

- Jeremy Whiting


On June 29, 2016, 5:27 a.m., Marco Martin wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128317/
> ---
> 
> (Updated June 29, 2016, 5:27 a.m.)
> 
> 
> Review request for KDE Frameworks and Aleix Pol Gonzalez.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> the recent change ed0a1be18ec5b421fc1319d2a28f118d9ea324b9 made the download 
> dialog fail if a category is not found.
> 
> this fixes the dialog showing completely unrelated stuff, but it's too much.
> if even just one category is available, the safest way is to show whatever of 
> the available categories was found.
> the new server will have some category less (for instance most of the 
> categories like "KDE Wallpaper 800x600" will go, so in order to be compatible 
> with old clients, it needs to show content even if one of the categories are 
> available)
> 
> 
> Diffs
> -
> 
>   src/attica/atticaprovider.cpp ad506cd 
> 
> Diff: https://git.reviewboard.kde.org/r/128317/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Marco Martin
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128219: No longer allow installing to generic data folder because of security hole.

[Jeremy Whiting]

> On June 17, 2016, 1:36 a.m., David Faure wrote:
> > src/core/installation.cpp, line 365
> > <https://git.reviewboard.kde.org/r/128219/diff/1/?file=469097#file469097line365>
> >
> > Should this code get support for "appdata" then?
> >  (typically share/kmyapp)
> >  
> > Otherwise I don't see where application data would get installed 
> > anymore.
> > 
> > Am I right that there must be lots of apps using "data" right now, for 
> > lack of "appdata" support?
> > Surely not every app using knewstuff, is using it for "tmp" or "config" 
> > files

I have a build of most of the "official" kde applications here. Not all of the 
possible .knsrc files by any means, but a good selection most likely. Looking 
at what I have here all uses of StandardResource were either tmp or wallpapers. 
Most applications use TargetDir instead and specify a path within appdata. 
apps/kvtml, color-schemes, cantor/examples etc. I couldn't see any at all here 
that are using StandardResource=data directly.

I guess I should do a more thorough search on lxr.kde.org though.

Ok, doing that 
https://lxr.kde.org/search?_filestring=.knsrc&_string=StandardResource&_casesensitive=1
 shows all StandardResource= being tmp or wallpaper. No uses of "data" at all.


> On June 17, 2016, 1:36 a.m., David Faure wrote:
> > src/core/installation.cpp, line 366
> > <https://git.reviewboard.kde.org/r/128219/diff/1/?file=469097#file469097line366>
> >
> > API misuse is normally rewarded with a q[C]Warning rather than a 
> > q[C]Debug.
> > 
> > The message should also mention what to use instead (depending on the 
> > result of the discussion in the previous comment).

Yep, I'll change to qCWarning, np and mention what to use instead.


> On June 17, 2016, 1:36 a.m., David Faure wrote:
> > src/core/installation.cpp, line 379
> > <https://git.reviewboard.kde.org/r/128219/diff/1/?file=469097#file469097line379>
> >
> > There are of course other values for targetDirectory which would create 
> > problems.
> > - "//"
> > - "./"
> > - "../etc"
> > - and so on
> > 
> > But this is a setting written by the app developer, not by the person 
> > uploading knewstuff data, so we can assume no malicious intention, right?

Yes only application developer. Or end user if they want to tweak the .knsrc 
files by hand to introduce a security vulnerability. Though if they wanted to 
do that there are much easier ways to do it.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128219/#review96621
---


On June 16, 2016, 7:55 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128219/
> ---
> 
> (Updated June 16, 2016, 7:55 p.m.)
> 
> 
> Review request for KDE Frameworks, David Faure and Richard Moore.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> When an application uses TargetDir=/ or StandardResource=data give a warning 
> on the terminal and don't use the chosen location.
> 
> 
> Diffs
> -
> 
>   src/core/installation.cpp cbd0653 
> 
> Diff: https://git.reviewboard.kde.org/r/128219/diff/
> 
> 
> Testing
> ---
> 
> No testing done yet, will write a unit test of some kind if this is the right 
> direction.
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 128219: No longer allow installing to generic data folder because of security hole.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128219/
---

Review request for KDE Frameworks, David Faure and Richard Moore.


Repository: knewstuff


Description
---

When an application uses TargetDir=/ or StandardResource=data give a warning on 
the terminal and don't use the chosen location.


Diffs
-

  src/core/installation.cpp cbd0653 

Diff: https://git.reviewboard.kde.org/r/128219/diff/


Testing
---

No testing done yet, will write a unit test of some kind if this is the right 
direction.


Thanks,

Jeremy Whiting

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128057: Don't initialize KNS3::DownloadManager with the wrong categories

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128057/#review96108
---


Ship it!




Ship It!

- Jeremy Whiting


On May 30, 2016, 9:12 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128057/
> ---
> 
> (Updated May 30, 2016, 9:12 a.m.)
> 
> 
> Review request for KDE Frameworks and Jeremy Whiting.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> If we request some unexisting categories, we'll get basically a list of all 
> resources in the OCS server, which is not what we want.
> For now, just emit an error instead so the front-end can react to it.
> 
> 
> Diffs
> -
> 
>   src/attica/atticaprovider.cpp 94f869e 
>   src/downloadmanager.h 0441742 
>   src/downloadmanager.cpp 9eca302 
> 
> Diff: https://git.reviewboard.kde.org/r/128057/diff/
> 
> 
> Testing
> ---
> 
> Tested with Plasma's comic.knsrc file and Discover, which triggers this 
> problem.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127997: Extend KNS3::Entry public API

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127997/#review95866
---



Sorry I missed the initial review request somehow. This looks good to me except 
for homepage. Homepage sounds to me like a web site url that gives more 
information about the KNS::Entry. Is that what you're using it for, or is it 
the download url of the asset? If the latter I suggest renaming homepage to url 
or downloadUrl or something more fitting. If the former, it looks good to me 
ship it.

- Jeremy Whiting


On May 24, 2016, 5:25 a.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127997/
> ---
> 
> (Updated May 24, 2016, 5:25 a.m.)
> 
> 
> Review request for KDE Frameworks and Jeremy Whiting.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> Exposes some API present in either EntryInternal or in Attica::Contents.
> 
> This allows Discover's KNS Backend to just use KNewStuff entries instead of 
> having to additionally fetch the information in Attica.
> 
> 
> Diffs
> -
> 
>   src/attica/atticaprovider.cpp 07508b0 
>   src/core/entryinternal.cpp b05fe24 
>   src/core/entryinternal_p.h 20f9b1b 
>   src/entry.h 6603e97 
>   src/entry.cpp 09f9542 
> 
> Diff: https://git.reviewboard.kde.org/r/127997/diff/
> 
> 
> Testing
> ---
> 
> Discover works as it used to, with many changes I have locally.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127900: Fix redirection of absolut Urls

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127900/#review95440
---


Ship it!




Ship It!

- Jeremy Whiting


On May 12, 2016, 11:17 a.m., Andreas Cord-Landwehr wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127900/
> ---
> 
> (Updated May 12, 2016, 11:17 a.m.)
> 
> 
> Review request for KDE Frameworks, Cornelius Schumacher and Kevin Funk.
> 
> 
> Bugs: 354748
> http://bugs.kde.org/show_bug.cgi?id=354748
> 
> 
> Repository: attica
> 
> 
> Description
> ---
> 
> Redirection only worked with relative urls. Yet, e.g. the http to https
> redirection on KDE servers uses absolute paths, which resulted in an
> empty url, since the reply attribute was not relative.
> 
> This patch adds a case distinction for redirecting absolut and relative
> paths.
> 
> BUG: 354748
> 
> 
> Diffs
> -
> 
>   src/atticabasejob.cpp f73cb432212be63cff2ae1118c602cc3bae6d615 
> 
> Diff: https://git.reviewboard.kde.org/r/127900/diff/
> 
> 
> Testing
> ---
> 
> Manual testing with GHNS for documentation in KDevelop.
> 
> 
> Thanks,
> 
> Andreas Cord-Landwehr
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 127887: Improve usage of Qt APIs

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/127887/#review95428
---



The knewstuff (non moretools) side looks good to me.

- Jeremy Whiting


On May 11, 2016, 5:01 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127887/
> ---
> 
> (Updated May 11, 2016, 5:01 p.m.)
> 
> 
> Review request for KDE Frameworks and Jeremy Whiting.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> Mostly clazy fixes, few cleanups
> 
> 
> Diffs
> -
> 
>   src/core/installation.cpp 1887d0f 
>   src/kmoretools/kmoretools.h 32da22c 
>   src/kmoretools/kmoretools.cpp 8bd6751 
>   src/kmoretools/kmoretoolsconfigdialog_p.cpp 466b887 
>   src/kmoretools/kmoretoolsmenufactory.cpp aad3f00 
>   src/kmoretools/kmoretoolspresets.cpp 679e849 
>   src/staticxml/staticxmlprovider.cpp 541bf57 
>   src/ui/itemsviewdelegate.cpp 7001be2 
>   tests/kmoretools/kmoretoolstest_interactive.cpp b1cbdea 
> 
> Diff: https://git.reviewboard.kde.org/r/127887/diff/
> 
> 
> Testing
> ---
> 
> Builds, tests pass.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [kde-community] Sunsetting of Infrastructure and the Phabricator migration

[Jeremy Whiting]

Just a note so everyone doesn't need to go google/search this
themselves. To see your scratch repositories look at quickgit.kde.org
and filter by your identity name. To delete old repos, do this:

ssh g...@git.kde.org D unlock scratch//reponame <--
notice no .git on the end, if you put .git it will just say "You are
not authorized"
ssh g...@git.kde.org D rm scratch//reponame

Hope that helps,
Jeremy

On Fri, Mar 18, 2016 at 12:46 AM, Ben Cooksley  wrote:
> == This mail is considered mandatory reading for all KDE Developers.
> Please read this email in whole. ==
>
> Hi all,
>
> As you'll all be aware we are currently in the process of overhauling
> our Git infrastructure, and replacing numerous elements of it.
>
> The first part of this will take place this weekend - with
> projects.kde.org being shutdown. All Git repository browsing from that
> point on should take place through quickgit.kde.org. commits.kde.org
> will also be reconfigured to redirect you exclusively to
> quickgit.kde.org.
>
> As a result the tree structure will only be available from the XML
> file from this point onward. There are no plans to replicate the tree
> structure within Phabricator (although some of the grouping it
> facilitates may be provided through a different mechanism)
>
> The XML file upon which numerous utilities (including kdesrc-build)
> depend will continue to be made available. It will instead be
> generated by a Python script periodically, based on the contents of a
> Git repository.
>
> In terms of Reviewboard, there are no plans to import it's contents
> into Phabricator, as the level of effort required is too high. Once we
> are migrated to Phabricator for reviews, i'm proposing that everyone
> has 4 weeks to finish any final reviews up within Reviewboard before
> it is set to read only by disabling login for everyone. Reviews still
> open at that point would be discarded.
>
> The contents of Kanboard will be migrated into Phabricator, more
> details will come on that over the next few weeks, including details
> of any action people needs to take. As an immediate measure it would
> be appreciated if people could conduct a general cleanup and remove
> tasks and boards they have no intention of using or revisiting in the
> future. Following this migration Kanboard will be shutdown.
>
> In terms of repositories, now would be a good time to look into the
> scratch and clone repositories you have on git.kde.org and perform a
> cleanup of any repositories which are unused, not useful or are
> otherwise no longer needed.
>
> We will be looking into how to import our repositories into
> Phabricator which will include all scratch and clone repositories.
> This means the entire content of these repositories will be indexed,
> and reducing the number of repositories will reduce the amount of
> indexing work which Phabricator needs to complete.
>
> I should also note that as a side affect of the Phabricator
> transition, scratch/clone repositories will to a certain extent cease
> to exist - everything will now be a mainline repository. As a
> consequence force pushes will be disabled for all repositories as part
> of the migration (including scratch repositories). We will be creating
> a mechanism which will allow repositories following certain naming
> conventions to be easily created by developers (although this will
> have to be done through the web interface).
>
> As part of the capabilities of Phabricator, sysadmin will also be
> extending the power to create general purpose mainline repositories
> (and certain other actions within Phabricator) to a number of
> community members. They will be contacted individually over the next
> month or two regarding this.
>
> Comments on the above are welcome (little is in concrete yet), please
> start them in appropriate sub-threads on kde-core-devel (to minimize
> cross-posting, etc).
>
> Thanks,
> Ben Cooksley
> KDE Sysadmin
> ___
> kde-community mailing list
> kde-commun...@kde.org
> https://mail.kde.org/mailman/listinfo/kde-community

Re: remove khelpcenter from next Plasma release?

[Jeremy Whiting]

As an application developer I agree it makes sense to have khelpcenter
released with KDE Applications. I also agree with Albert's point that
having online documentation isn't the best since it could be newer
than what's actually running. People using LTS distributions or
"stable" variants of less often released distributions will have very
old (to those of us that run from git) versions of stuff. Having
online documentation for plasma 5.7 to look at while you're running
plasma 4 would just confuse.

Also, thanks Luigi for stepping up to maintain it.

BR,
Jeremy

On Tue, Mar 15, 2016 at 4:11 PM, Luigi Toscano  wrote:
> Luigi Toscano ha scritto:
>> On Wednesday 09 of March 2016 16:50:39 Sebastian Kügler wrote:
>>> On Wednesday, March 09, 2016 17:30:01 Luigi Toscano wrote:
> Let me cut right to the chase, do you want to maintain it? Does it need
> to
> be in Plasma?

 Yes, I can maintain it. In fact many features come from components I
 already  control.

> You're right that Plasma devs don't seem to want it, I thought my
> initial
> email made that pretty clear. We do think that disconnected systems are
> rather a fringe case, and that our time and effort is better spent on
> other
> things.

 Then the question still holds: with a maintainer, does it have a place in
 Plasma? I'm not talking about an hypothetical time and effort for
 maintaining  this offline use case (which will continue to be 0) but in
 the
 light of the statement above. In other words, if the question mark in the
 subject is real or rhetorical.
 I'm ready for both possible outcomes.
>>>
>>> Ah OK, sorry for misunderstanding it.
>>>
>>> I think there are the following options:
>>>
>>> 1) keeping it in Plasma with maintainer
>>> 2) keeping it outside of Plasma with maintainer
>>> 3) moving it to unmaintained (that's basically killing it)
>>> 4) keeping the status quo (not wanted)
>>>
>>> My personal preference would be an optional component (hence Extragear),
>>> since I think that the vast majority of users has web access, so
>>> khelpcenter isn't necessary and only adds to our maintainance burden
>>> without much gain in those cases.
>>
>> My offer stands and we can rule out 4) and 3).
>> Note that 2) could also mean a move to Applications (from your point of view
>> it does not matter too much).
>> The case 1) shouldn't add maintenance anyway as the maintainer is identified.
>>
>>>
>>> If we can move from 4) to 1) (so status quo but with maintainer), that would
>>> already be an improvement of course.
>>>
>>> The question mark was honest, we haven't made a decision on it, but
>>> different people do have expressed a preference for not shipping it (as or
>>> by default in Plasma releases). We may have missed important points, and we
>>> don't want to just kick things out unilaterally.
>>
>> I think we can leave some time for other people to comment. The shortest
>> deadline of all possibilities is the one for moving into Applications, and
>> there are still 8 days before the dependency freeze and two weeks before the
>> branch.
>
> Any other comment from anyone else?
>
> Ciao
> --
> Luigi
> ___
> Plasma-devel mailing list
> plasma-de...@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Minuet (music education software) moved to kdereview

[Jeremy Whiting]

Sandro,

We have a mixture of both in kde-edu. I know kanagram and khangman use
their own versioning numbers. If no changes happen between releases we
don't bump the version number. If they do we do. I think at some point
when it's pretty solid you may want to consider using the KDE
Applications version numbering, but to start off, using 0.1, 0.2 etc.
to indicate that it's a new project makes sense.

BR,
Jeremy

On Mon, Feb 8, 2016 at 12:21 PM, Sandro Andrade  wrote:
> On Mon, Feb 8, 2016 at 2:44 PM, Sandro Andrade  wrote:
>> On Sun, Jan 31, 2016 at 8:42 PM, Aleix Pol  wrote:
>>> On Mon, Feb 1, 2016 at 12:30 AM, Albert Astals Cid  wrote:
 El Tuesday 26 January 2016, a les 10:15:47, Andreas Cord-Landwehr va 
 escriure:
> On Monday 25 January 2016 21:48:27 Albert Astals Cid wrote:
> > El Sunday 24 January 2016, a les 16:50:18, Andreas Cord-Landwehr va
>
> escriure:
> > > * it looks strange to me that in minuet/cmake/ there are Config-files
> > > for
> > > the 3rd-party library drumstick. My understanding was that such Config
> > > files should only be shipped with the respective library (maybe 
> > > someone
> > > with a deeper CMake-knowledge can comment?)
> >
> > If upstream ships a cmake file awesome, but if not then we have to find 
> > it
> > having our own cmake file.
>
> Absolutely, but shouldn't that be find-files then instead of config-files?
> I always had the perception that those are quite different.

 Right, it most probably be a Find file not a Config file, as far as I
 understand it Config files are mostly for projects that ship the cmake 
 file as
 part of their install.

 Can someone with more cmake knowledge comment?
>>>
>>> Yes, the idea is that *Config.cmake files should be distributed by the
>>> framework itself, otherwise you need to find it. It probably works
>>> though, because such things are seldom checked within cmake though.
>>>
>>> I suggest turning it into a normal Find*.cmake file. Or get Drumstick
>>> to provide a cmake file, which is always more convenient.
>>
>> Hi,
>>
>> I've changed CMakeLists.txt to find out drumstick libs using 
>> pkg_check_modules,
>> which is the way other drumstick clients (like KMetronome, KMidimon)
>> actually do.
>> I confirm that works fine at least in Arch, KUbuntu, openSUSE, and Fedora 
>> (other
>> distros should package drumstick's pkg-config files similarly).
>>
>> The three weeks period (two weeks review + one week after completion
>> of requested changes)
>> ends tomorrow. I plan to move it to KDE edu by the end of this week,
>> so that further suggestions
>> are quite welcome :)
>>
>> Also, could someone clarify the questions I raised before? (copied below)
>>
>> * Regarding Minuet versioning itself: should I use the automatic version
>> numbering from release script or should I start from a 1.0.0 release?
>> * Also, where are those release scripts stored (some repository)?
>
> That seems to be the release-tools.git repository. Following the version
> numbering of KDE Applications would be nice for consistency but it may
> not reflect the fact Minuet is yet in its early days.
>
> Suggestions?
>
> Sandro
>
>>
>> Cheers,
>> Sandro
>>
>>>
>>> Aleix

Re: Review Request 126948: Simplify attica plugin look-up and initialization

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126948/#review91908
---


Ship it!




Ship It!

- Jeremy Whiting


On Feb. 1, 2016, 12:37 p.m., Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126948/
> ---
> 
> (Updated Feb. 1, 2016, 12:37 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: attica
> 
> 
> Description
> ---
> 
> Just use QPluginLoader instead of doing it locally (and with an awkward 
> blocking QProcess call)
> 
> 
> Diffs
> -
> 
>   src/providermanager.cpp 0536a1f 
> 
> Diff: https://git.reviewboard.kde.org/r/126948/diff/
> 
> 
> Testing
> ---
> 
> Test still passes, initializing attica still finds the right plugin on my 
> system.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 126039: When configfile is loaded from resource, do not issue file not found error

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/126039/#review89265
---

Ship it!


Works for me, sorry I missed this somehow.

- Jeremy Whiting


On Nov. 12, 2015, 4:15 p.m., Andrew McCann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/126039/
> ---
> 
> (Updated Nov. 12, 2015, 4:15 p.m.)
> 
> 
> Review request for KDE Frameworks, Christoph Cullmann and Jeremy Whiting.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> When configfile is loaded from resource, do not issue file not found error.
> 
> Encountered this problem while attempting to make KDevelop work on OSX as an 
> app bundle.
> 
> Concretely, the logic error here is that the file actually is loaded and is 
> aborting early. 
> 
> If the file were actually not found, the following code block that tests for 
> validity will error anyway.
> 
> 
> Diffs
> -
> 
>   src/core/engine.cpp 56912ddfa8312ea6233aecffda296f041b180237 
> 
> Diff: https://git.reviewboard.kde.org/r/126039/diff/
> 
> 
> Testing
> ---
> 
> Verify that loading configfile from qt5's resource system ex 
> ":/kconfig/test.knsrc" now works and didn't before.
> 
> 
> Thanks,
> 
> Andrew McCann
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KNotifications filters

[Jeremy Whiting]

Yeah, that makes sense. Ok will do.

On Sun, Dec 6, 2015 at 3:37 AM, David Faure <fa...@kde.org> wrote:
> On Thursday 24 September 2015 20:35:24 Jeremy Whiting wrote:
>>  If so I guess the logical place for it would be a TTS group in
>> kdeglobals, does that make sense?
>
> Stay away from kdeglobals :-)
> It forces every app to parse that stuff even if they don't need it.
>
> Framework-specific config can go into a framework-specific config file,
> it doesn't have to be kdeglobals.
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Porting apps to KF5

[Jeremy Whiting]

Harshit Dwivedi,

I think the reason you can't find applications that are "live" that haven't
been ported is because any live project has developers working on it that
have already ported it. That said many of the non live projects need to be
ported at some point and we can help review those porting efforts here, so
feel free to take a stab at porting any of those you see on that list. Do
check if there's an existing frameworks or kf5 branch to start from though,
many of them have a branch with that sort of name as a starting point.

BR,
Jeremy

On Mon, Dec 7, 2015 at 6:37 AM, Harshit Dwivedi 
wrote:

> Hello,
> I am interested in porting apps to KF5.
> I have already had a look at the projects available on
> http://developer.kde.org/~cfeck/portingstatus.html but most of the
> projects that have not been ported have commits that are over 1 year old.
>
> So could you please guide me towards any live project that has not been
> ported yet so that I can help on porting it.
>
> Thanks,
> Harshit Dwivedi.
>
>
>
>
>
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> unsubscribe <<
>
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: MacPorts Patches

[Jeremy Whiting]

Boudhayan,

I'm not sure why you think the MacPorts approach has anything to do
with running a full KDE experience. Macports is just a packaging
system, and in KDE's aspect of MacPorts it's only to get our
applications and libraries, there's no intent that I've seen anywhere
with MacPorts (or Windows either) to run plasmashell etc.

BR,
Jeremy

On Mon, Nov 30, 2015 at 7:05 AM, Boudhayan Gupta  wrote:
> Hi all,
>
> We've suddenly been having an influx of MacPorts specific patches, and
> most of them have ended up generating some sort of controversy because
> what I perceive to be some differences in envisioned use-cases.
>
> Unless I'm much mistaken, the "full KDE experience", if I may call it
> that, is intended to be provided on Linux, BSD, Solaris(?) etc where
> you can install and run the Plasma Workspace as your primary desktop
> experience. In these cases, Plasma takes over system and session
> functionality, and we need all these invasive code that reaches deep
> into the system APIs.
>
> On platforms where the "full KDE experience" isn't available, my
> assumption is that we're supposed to provide application bundles
> (.application on Mac, bundled .exe installers on Windows) which
> include the application and all its dependencies in one single
> package. These applications are supposed to behave exactly like other
> applications on these platforms - there should be no difference
> between how say Keynote presents itself on Mac to how Calligra Stage.
>
> MacPorts seems be going on a tangent that no KDE developer is
> interested in - trying to get as much of the "full KDE experience" as
> possible on a platform where it's clearly going to be very half-baked
> and unusable (pretty much a gimmick) because we really can't latch on
> and grab that kind of low level system and session management stuff in
> OSX anyway.
>
> I'm of the opinion that we shouldn't be admitting invasive
> MacPorts/Fink (or even KDE on Windows) patches that attempt to reach a
> goal of running a full Plasma session on any such platform (or even
> attempt to package-managerise KDE on such platforms). But this is a
> community, and it should be left to decide what it wants on its own.
> That said, we should really lay down official policy soon before
> discussing the current MacPorts patches any further, because pretty
> much every thread is devolving into heated arguments that's taking up
> developer time as well as making them feel not happy.
>
> Yours,
> Boudhayan Gupta
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Maintenance of api.kde.org

[Jeremy Whiting]

Alex,

Last time I checked api.kde.org was generated by scripts in the
websites/quality-kde-org git repository. It includes instructions for
installing it locally, though the instructions are a bit outdated. I
think perl's setup scripts have changed since it was written since I
needed to tweak the install script to get it to install here (when I
was looking into it about 8 months ago or so). Poke me if you hit the
same issues and I can put a patch up on reviewboard if it's still
around my hard drive here somewhere...

thanks,
Jeremy

On Thu, Nov 5, 2015 at 4:58 PM, Alex Merry  wrote:
> On 2015-11-05 09:22, Ben Cooksley wrote:
>>
>> Hi all,
>>
>> For some time it has been apparent that api.kde.org is experiencing
>> some issues with maintenance. It doesn't really fall into sysadmin's
>> domain, but developers often lack the knowledge on how to get Doxygen
>> working as needed to build projects API documentation. This isn't
>> helped by the setup not being simple for easy local testing.
>>
>> Any volunteers to look into it, fix some issues and generally make it
>> easier to work with for the future?
>
>
> This is my domain really, as maintainer of kapidox - kapidox was intended to
> make this simpler and easier, but currently it's only run on frameworks. I
> don't really know much about the automation on api.kde.org itself, though,
> and we need to figure out how to choose whether to run kapidox, kdelibs4's
> apidox generation scripts, or no apidox generation at all for a given
> project.
>
> I'm willing to put some time into this, but I'd need to be able to at least
> mirror api.kde.org's setup locally to try tweaking and testing things -
> going through Allen Winter every time I want to test something out (and then
> waiting for the cron jobs or whatever to run) is just too slow of a feedback
> cycle.
>
> Alex

Re: Maintenance of api.kde.org

[Jeremy Whiting]

Alex,

Last time I checked api.kde.org was generated by scripts in the
websites/quality-kde-org git repository. It includes instructions for
installing it locally, though the instructions are a bit outdated. I
think perl's setup scripts have changed since it was written since I
needed to tweak the install script to get it to install here (when I
was looking into it about 8 months ago or so). Poke me if you hit the
same issues and I can put a patch up on reviewboard if it's still
around my hard drive here somewhere...

thanks,
Jeremy

On Thu, Nov 5, 2015 at 4:58 PM, Alex Merry  wrote:
> On 2015-11-05 09:22, Ben Cooksley wrote:
>>
>> Hi all,
>>
>> For some time it has been apparent that api.kde.org is experiencing
>> some issues with maintenance. It doesn't really fall into sysadmin's
>> domain, but developers often lack the knowledge on how to get Doxygen
>> working as needed to build projects API documentation. This isn't
>> helped by the setup not being simple for easy local testing.
>>
>> Any volunteers to look into it, fix some issues and generally make it
>> easier to work with for the future?
>
>
> This is my domain really, as maintainer of kapidox - kapidox was intended to
> make this simpler and easier, but currently it's only run on frameworks. I
> don't really know much about the automation on api.kde.org itself, though,
> and we need to figure out how to choose whether to run kapidox, kdelibs4's
> apidox generation scripts, or no apidox generation at all for a given
> project.
>
> I'm willing to put some time into this, but I'd need to be able to at least
> mirror api.kde.org's setup locally to try tweaking and testing things -
> going through Allen Winter every time I want to test something out (and then
> waiting for the cron jobs or whatever to run) is just too slow of a feedback
> cycle.
>
> Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125884: Set default value for WheelScrollLines

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125884/#review87824
---

Ship it!


Ship It!

- Jeremy Whiting


On Oct. 30, 2015, 3 p.m., David Rosca wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125884/
> ---
> 
> (Updated Oct. 30, 2015, 3 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: frameworkintegration
> 
> 
> Description
> ---
> 
> Use 3 (same as mouse kcm) as default value instead of 
> QApplication::wheelScrollLines().
> 
> 
> Diffs
> -
> 
>   src/platformtheme/khintssettings.cpp e5c362a 
> 
> Diff: https://git.reviewboard.kde.org/r/125884/diff/
> 
> 
> Testing
> ---
> 
> No longer sets 0 lines when WheelScrollLines entry is not in kdeglobals.
> 
> 
> Thanks,
> 
> David Rosca
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Debug ThreadWeaver::IdDecorator

[Jeremy Whiting]

Or install the debuginfo package from your distro...

On Wed, Oct 28, 2015 at 6:38 AM, Olivier Churlaud  wrote:
>
> Hi,
>
> Le 26/10/2015 21:02, Thiago Macieira a écrit :
>>
>> On Sunday 25 October 2015 21:19:52 Olivier Churlaud wrote:
>>>
>>> #0  0x70e497d4 in ThreadWeaver::IdDecorator::~IdDecorator() ()
>>>  from /usr/lib/libKF5ThreadWeaver.so.5
>>> #1  0x70e50385 in ?? () from /usr/lib/libKF5ThreadWeaver.so.5
>>
>> It would help if you recompiled the ThreadWeaver library in debug mode so
>> we
>> can see what the ?? are.
>
> Thx for your hint. I compiled ThreadWeaver successfully but I don't know
> how to tell cmake to link it to this version of ThreadWeaver (and not
> the one in /usr/lib64)
>
> I added this to the cmake command:
> -DCMAKE_PREFIX_PATH=/home/olivier/Projets/threadweather/build/install
>
> it didn't work.
>
> For information,  the CmakeList.txt contains:
>
> find_package( KF5 REQUIRED COMPONENTS CoreAddons Solid KDELibs4Support
> Codecs I18n ThreadWeaver Plasma PlasmaQuick KCMUtils NewStuff TextEditor
> GlobalAccel KIO NotifyConfig Archive DNSSD)
>
> I cleaned my /build folder with a rm -rf.
>
> Cheers,
> Olivier
>
>
>
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Review Request 125767: Make KConfigWidgets self contained, bundle the one global file in a resource

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125767/#review87363
---

Ship it!


Ship It!

- Jeremy Whiting


On Oct. 23, 2015, 12:57 p.m., Christoph Cullmann wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125767/
> ---
> 
> (Updated Oct. 23, 2015, 12:57 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> ---
> 
> Make KConfigWidgets self contained, bundle the one global file in a resource
> Mark as working on all opsys, does work OK on win & mac
> 
> 
> Diffs
> -
> 
>   metainfo.yaml 48cf5b6 
>   src/CMakeLists.txt 10862c6 
>   src/kconfigwidgets.qrc PRE-CREATION 
>   src/ktipdialog.cpp 25559b6 
> 
> Diff: https://git.reviewboard.kde.org/r/125767/diff/
> 
> 
> Testing
> ---
> 
> compiles, looks ok.
> 
> 
> Thanks,
> 
> Christoph Cullmann
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

+1 and thanks for adding documentation.

On Fri, Oct 23, 2015 at 9:53 AM, Aleix Pol  wrote:
> On Thu, Sep 10, 2015 at 10:32 AM, Albert Vaca  wrote:
>> Hi,
>>
>> With the latest changes we are making to KDE Connect as part of the sprint
>> in Randa, I think that the project is becoming mature enough to be moved out
>> of playground. Not only that, but Kubuntu and other distros are already
>> installing KDE Connect by default, regardless of it being in playground.
>>
>> I think that extragear/network is the best place for KDE Connect to be in,
>> as we don't want to be tied to external release schedules for now.
>>
>> Any thoughts?
>>
>> Albert
>>
>>
 Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
 <<
>>
>
> Hi,
> There's some documentation for the KCM now.
>
> Should we move forward?
> Aleix
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: [KDE/Mac] Question about goal of Windows/Mac frameworks

[Jeremy Whiting]

Yeah, if we go that direction on mac it would be fine for bundled Qt,
but not for shared Qt. It would make all applications that use qt5-mac
or qt5-kde or whatnot use linuxy paths or not. It's a runtime switch,
so not very helpful if you've installed stuff to linuxy paths and then
let the user choose to toggle it and fail to find all the resources
needed. It sounds like a good solution for embedding a copy of Qt next
to each application for windows use (and maybe for osx use too if
resources don't make it completely unneccessary), but not for the
macports shared Qt case.

On Thu, Oct 22, 2015 at 2:37 PM, René J.V.  wrote:
> On Thursday October 22 2015 22:05:59 Marko Käning wrote:
>
>> > https://bugreports.qt.io/browse/QTBUG-44473?focusedCommentId=272971=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-272971)
>> > Because the proposal supports environment variables too, I guess this
>> > would also cover the OS X needs (env XDG_CONFIG_DIRS).
>>
>> that actually slipped my attention back then! :-|
>>
>> OK, perhaps that is a way to go then also for MacPorts?! @René?
>
> I understood from Jeremy's reply at the time that it wasn't exactly what we'd 
> need. I'm not familiar with how qt.conf is to be used, but my 1st impression 
> is that neither a per-app-bundle qt.conf nor a central, shared one would be 
> the perfect solution. The per-application approach will be much more 
> maintenance-heavy, and a central, shared file would mean that all 
> applications depending on Qt5 use either the one or the other QSP "flavour".
>
>
> R.
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125656: Drop empty files

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125656/#review87199
---

Ship it!


Ship It!

- Jeremy Whiting


On Oct. 21, 2015, 4:29 a.m., Maximiliano Curia wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125656/
> ---
> 
> (Updated Oct. 21, 2015, 4:29 a.m.)
> 
> 
> Review request for KDE Frameworks and Jeremy Whiting.
> 
> 
> Repository: knewstuff
> 
> 
> Description
> ---
> 
> Currently the file src/core/upload.cpp is under a LGPL-2 only license, and
> shipping the corresponding full license is required. Which is incompatible
> with the current frameworks policy. The mentioned file and the private header
> src/core/upload_p.h are currently "empty", as they contain only commented out
> functions. And these files are not part of the API, so it's safe to drop them.
> 
> 
> Diffs
> -
> 
>   src/core/upload.cpp 486129b55bb108f965050ecc25df7e6d98bebb9e 
>   src/core/upload_p.h 4fa38689f64a0dec94666962a7541dd3d6086482 
> 
> Diff: https://git.reviewboard.kde.org/r/125656/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Maximiliano Curia
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Jeremy Whiting]

Christoph,

I'm not trying to argue against having applications come in complete
bundles at all. That is a worthy goal also actually, it's just not the
direction I was headed in. You've made a lot more progress in this
regard than I had though tbh. I see the kdewin installer as something
that went away because it was tricky to set up, had a bus number of
one (I think only Saro was creating repositories for it iirc), so it
fell by the wayside at some point. I did use it to install my favorite
kde utilities on windows whenever I was stuck on windows for various
reasons though. It was useful to install ksnapshot, filelight, etc.
and have them use the same copy of kdelibs. Maybe with frameworks it's
not that important to share libraries between applications though. I'm
not sure.

I can understand arguments for both ways of doing things. Having each
application have it's own copy of Qt, KF5, etc. makes it possible to
know that those versions have been tested with the application code to
make sure it runs well etc. If applications are sharing one copy of Qt
and one of them upgrades it, it's not guaranteed to work the same way
as an older version (it's supposed to work, but I've seen enough
e-mail about Qt 5.x breaks plasma where it worked with Qt 5.x-1 to
know this isn't always the case in reality.)

Also, the work you're doing to make frameworks use bundled resources
will help both of the above use cases, so that's definitely an
improvement in my opinion.

I can see advanced users either using macports, fink, homebrew or a
download and install x,y,z and share libraries to install many of our
applications. I can also see the same power users recommending
individual applications to their relatives (moms, grandmothers, etc.)
using single application installers as you described. "Here mom,
download this one bundle to install kxstitch on your windows laptop."
etc. So there are advantages to both/all ways of going forward I
think.

BR,
Jeremy

On Tue, Oct 20, 2015 at 1:19 PM, Alexander Neundorf  wrote:
> On Tuesday, October 20, 2015 20:23:00 Christoph Cullmann wrote:
>
>> Hi,
>
>>
>
>> > Christoph.
>
>> >
>
>> > I have had similar goals for a while, but haven't reached the point
>
>> > that I was having much success yet in that regard. One thing to keep
>
>> > in mind when developing installers, Qt Installer Framework. I did a
>
>> > quick test with attica on OS X I can put on reviewboard to see what
>
>> > you think. I added a few lines to CMakeLists.txt to make it so you can
>
>> > do make package, and it uses CPack and Qt Installer Framework to
>
>> > create an installer application which can be used to download both
>
>> > attica and attica-devel packages for OSX. I bet we could put together
>
>> > a "meta" package for at least KF5 and maybe more which would consist
>
>> > of a CMakeLists.txt and a bunch of git clones beneath it could be used
>
>> > to create one OSX or Windows installer that could then be used to
>
>> > download applications and all their dependencies. I wasn't sure how to
>
>> > add dependency information to the result of CPack's QIFW generator,
>
>> > but it should be doable.
>
>> >
>
>> > The result of all of that would be one tool for OS X and a similar one
>
>> > for Windows that work exactly like the Qt online installers. Qt's
>
>> > online installers are meant for developers though, not end users, so
>
>> > we may need to improve QIF itself to make the resulting installer more
>
>> > user friendly, we'll see. I meant to blog about all of this a week or
>
>> > so ago, but haven't gotten around to it. What do you think of the idea
>
>> > in general though?
>
>>
>
>> I am not really a fan of that idea, to be honest.
>
>>
>
>> I think that is more or less what we had in the past with the "kdewin"
>
>> installer, that is like the cygwin installer pulling in all stuff you need
>
>> and a set of applications in some common prefix.
>
>>
>
>> I am not sure that was such a success, compared to what e.g. Krita,
>> Marble,
>
>> Digikam and others do: individual self-contained installers (or bundles).
>
>>
>
>> I really think we should focus on making frameworks fit for that and not
>
>> rebuilding some "micro-distro" with online installer for that operating
>
>> systems.
>
>>
>
>> But that is just my opinion, perhaps I am wrong with that.
>
>
>
> I fully agree with your POV.
>
>
>
> Alex
>
>
>
>
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Question about goal of Windows/Mac frameworks

[Jeremy Whiting]

Christoph.

I have had similar goals for a while, but haven't reached the point
that I was having much success yet in that regard. One thing to keep
in mind when developing installers, Qt Installer Framework. I did a
quick test with attica on OS X I can put on reviewboard to see what
you think. I added a few lines to CMakeLists.txt to make it so you can
do make package, and it uses CPack and Qt Installer Framework to
create an installer application which can be used to download both
attica and attica-devel packages for OSX. I bet we could put together
a "meta" package for at least KF5 and maybe more which would consist
of a CMakeLists.txt and a bunch of git clones beneath it could be used
to create one OSX or Windows installer that could then be used to
download applications and all their dependencies. I wasn't sure how to
add dependency information to the result of CPack's QIFW generator,
but it should be doable.

The result of all of that would be one tool for OS X and a similar one
for Windows that work exactly like the Qt online installers. Qt's
online installers are meant for developers though, not end users, so
we may need to improve QIF itself to make the resulting installer more
user friendly, we'll see. I meant to blog about all of this a week or
so ago, but haven't gotten around to it. What do you think of the idea
in general though?

thanks,
Jeremy

On Tue, Oct 20, 2015 at 12:04 PM, Christoph Cullmann
 wrote:
> Hi,
>
>> Hi,
>> With my Android hat on I very much welcome the initiative. Android is
>> more limited in this regard, as you will mostly always want to have
>> split packages there and it's how we've been working since the
>> beginning.
>>
>> I think that for us Qt is a safe base in general. relying on other 3rd
>> parties makes things a bit more complex. (e.g. dbus or gstreamer) It's
>> always arguable that it is possible to run, but then it can be a
>> burden. While on Linux it's preferable to leverage on the system
>> infrastructure, we can't expect these to be available elsewhere.
>>
>> I can agree to the 3 goals you mentioned, but they feel fuzzy:
>> 1) Fully agreed
> 1) Stock Qt
>
>> 2) What's Global stuff? This could be phrased as: "Frameworks should
>> only require resources that can be located with QStandardPaths and can
>> be distributed in bundles."
> Badly phrased, yes, I think 2) is more like:
>
> 2) Can be self-contained shipped in an application bundle (self-installer/mac 
> app bundle).
>
>> 3) non-existing stuff? really? Let's rephrase it as: "Frameworks will
>> only be advertised as available on a platform if they are just require
>> Qt or other available dependencies on the platform". For example,
>> requiring libssh could be an acceptable dependency.
>>
>> Regarding dbus especifically, I see the problem in 2). You can bundle
>> it, but then if it's already ran by another process the other one will
>> have to be used, which is where the dbus mess starts.
> Yeah, 3) is perhaps more like:
>
> 3) Frameworks shall require only libraries shipped with the target operating 
> system
> per default (which is quiet well defined on Win/Mac, but not that well 
> defined on Linux).
>
> That additional stuff might be useful/recommended is clear, IMHO, like you 
> can have
> nice git integration if you have libgit2 for KTextEditor, but it works 
> without.
>
> Greetings
> Christoph
>
> --
> - Dr.-Ing. Christoph Cullmann -
> AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
> Science Park 1 Tel:   +49-681-38360-22
> 66123 Saarbrücken  Fax:   +49-681-38360-20
> GERMANYWWW:   http://www.AbsInt.com
> 
> Geschäftsführung: Dr.-Ing. Christian Ferdinand
> Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Project proposal for Season of KDE

[Jeremy Whiting]

Yeah, he said KDF

On Tue, Oct 20, 2015 at 5:22 PM, Aleix Pol  wrote:
> On Tue, Oct 20, 2015 at 8:55 PM, Harshit Dwivedi  
> wrote:
>> Hello Everyone,
>>
>> I would like to send my proposal for SOK . Please try and consider it.
>>
>>
>> Name: Harshit Dwivedi
>>
>>
>> Country: India
>>
>>
>> Project Title: Porting to KF5
>>
>>
>> Project Description: I have looked into KDF and i think i can try and port
>> it to KF5 with support and help of mentor. First I will start with Build
>> System then moving on to UI, then to KDE Core where i might need some help.
>>
>> I also wanted to know whether this project is currently active or not, as
>> the last commit to this was about 6 months ago.
>>
>>
>> Technical Requirements: Qt, QML, KF5
>>
>>
>> Time-line: My availability and other commitments during period: I have my
>> papers from 20th November to 25th December so i will not be available during
>> this period but after that period I will be fully committed to KDE Project.
>> Firstly I will be moving on with porting of build system and then moving on
>> to port with support of KDE4LibsSupport and porting UI afterwords.
>>
>>
>> Why me: I have past experience in contributing to various OSS like
>> Cyanogenmod and i am comfortable with OOPs, algorithms and Qt.
>>
>> Regards,
>> Harshit.
>>
>>
 Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
 <<
>>
>
> Hi Harshit,
> I don't think you're saying on your proposal what you want to port...
>
> Aleix
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Jeremy Whiting]

Ok, I just removed ksnapshot from the release-tools script. It won't
be included in Applications 15.12 releases.

On Sun, Oct 18, 2015 at 8:46 AM, Ivan Čukić  wrote:
>> Oh yes, I had completely forgotten about that. Thank you so much for
>> bringing this to notice, Ivan!
>
> No problem. I've noticed the issue when I wanted to submit a couple of
> bugs/wishlist things. :)
>
> Cheers,
> Ivan

Re: Cervisia?

[Jeremy Whiting]

Awesome! Keep it up. Porting to Qt5/KF5 can happen on a branch and be
done a small bit at a time if you like. There are also some scripts in
kdesdk/kde-dev-scripts/kf5 that can help with the trivial changes.
Most are executed like find -iname *.cpp | xargs scriptname, but if
not they will say in a comment at the top of the script how to execute
them.

On Thu, Oct 15, 2015 at 8:02 PM, Martin Koller <kol...@aon.at> wrote:
> On Thursday 15 October 2015 15:49:32 Jeremy Whiting wrote:
>> Michael, Martin,
>>
>> Any progress on the cervisia front? Is there anything I can do to help?
>
> yes, a lot of progress!
> We have already ported away from Qt3/KDE3 support classes.
> This is already in master and I'm testing it by using it on a daily basis.
>
> The next step would now be to start the port to KF5 - this has not been 
> started yet.
>
> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> ()  ascii ribbon campaign - against html e-mail
> /\- against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

Re: Krfb

[Jeremy Whiting]

Ok, frameworks branch merged to master now. I'll delete the frameworks
branch now too. I updated the logical-module-structure and translation
branches on projects.kde.org already also.

thanks,
Jeremy

On Sat, Oct 10, 2015 at 5:37 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El Saturday 10 October 2015, a les 04:41:32, Jeremy Whiting va escriure:
>> Yeah, that's the latest. I e-mailed Urs about krdc and mentioned krfb
>> also.  He suggested asking for a general review, so that's what this
>> is now.
>
> Looks good to me, could not find anything wrong and seems to work fine.
>
> Cheers,
>   Albert
>
>>
>> thanks,
>> Jeremy
>>
>> On Sat, Oct 10, 2015 at 3:26 AM, Albert Astals Cid <aa...@kde.org> wrote:
>> > El Friday 09 October 2015, a les 10:40:56, Jeremy Whiting va escriure:
>> >> Hello all,
>> >>
>> >> I've ported Krfb to kf5/qt5 on the frameworks branch.
>> >
>> > Last commit is September 17, did you forget to push some stuff or this is
>> > an email you wanted to write a while ago?
>> >
>> > Cheers,
>> >
>> >   Albert
>> >>
>> >> It seems to work
>> >> well here, but I am not the maintainer so thought it would be good if
>> >> others can take a look at the code also. If one or two people would
>> >> give it a try I would appreciate it. I'd like to merge frameworks
>> >> branch to master before the November Applications 15.12 dependency
>> >> freeze date. Note the following with the port.
>> >>
>> >> All telepathy tubes support has been removed since it doesn't work
>> >> well with existing telepathy protocols anyway after discussing with
>> >> kde-telepathy maintainers.
>> >>
>> >> thanks,
>> >> Jeremy
>> >>
>> >> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
>> >> >> unsubscribe
>> >> >> <<
>> >>
>> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>> >> <<
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Cervisia?

[Jeremy Whiting]

Michael, Martin,

Any progress on the cervisia front? Is there anything I can do to help?

thanks,
Jeremy

On Sat, Sep 26, 2015 at 8:25 PM, Michael Reeves <reeves...@gmail.com> wrote:
>
> On Sep 26, 2015 9:22 PM, "Jeremy Whiting" <jpwhit...@kde.org> wrote:
>>
>> Martin,
>>
>> Michael Reeves reeves...@gmail.com mentioned he would be interested in
>> helping also, maybe the two of you can get it ported away from
>> Qt3Support, then ported to Qt5/Kf5 ?
>>
>> thanks,
>> Jeremy
>>
> Sounds like a plan. I don't have write access to the repo. I too have
> limited time.

Re: Policy for Dependencies

[Jeremy Whiting]

I'd like to weigh in a bit here too. I agree with Boud and Christoph,
most users (developers of applications) of KF5 that aren't KDE
community members will be building the frameworks themselves. At my
last job we built Qt ourselves on all the platforms we targetted and
shipped shared libraries with the application like Boud has said. We
even had scripts that would set LD_LIBRARY_PATH to the application
folder so our Qt was preferred over any system Qt for linux.

I also agree with what Martin said a few emails ago. Applications we
are distributing on non kde platforms (or maybe even when running them
on GNOME?) should probably not use knotifications, etc. Though that
would remove a bit of their functionality. Personally I'd like to see
stuff like knewstuff working on windows/mac, but can't imagine it will
since it uses kio heavily (and thus needs kdeinit, etc.). I think the
more modular we can get the KDE Frameworks the better.

BR,
Jeremy


On Wed, Oct 14, 2015 at 1:51 PM, Boudewijn Rempt  wrote:
> On Wed, 14 Oct 2015, Martin Klapetek wrote:
>
>> I have to agree with Harald here though, I would also expect
>> the frameworks to be bunch of pre-built dlls you just install
>> system-wide and build on top of that, not create your own
>> custom builds of everything, for every app with different features
>> combo. At which point this all wouldn't be so much of a problem
>> I believe.
>
>
> Erm... The very _idea_ that you'd install a bunch of dll's system-wide
> on Windows or OSX or Android is... Words, at least, polite words, fail
> me. It's not just not done, it's actively wrong. (Note that ministro's
> way of doing shared Qt libraries no longer works in the most recent Android
> either, it's not a counter example.)
>
> I've been trying to get this point across at least since the desktop
> summit in berlin, and I guess I'm just congenitally incapable of stringing
> words together into an intelligible narrative because I'm failing _hard_.
>
> Fink, macports, emerge, cygwin and all the other refuges for Linux
> developers who have to use Windows or decide to defect to OSX are totally
> and utterly irrelevant. If you want to make a library that's used for a
> cross-platform application, that is.
>
> There is _one_ way to package your application for Windows, and that is
> create an installer that packages everything, every dependency that the
> application needs _including_ the msv c runtime dll. Everything else
> will not get your application in your user's hands.
>
> There are _two_ ways to package your application for OSX: as an app bundle
> in a disk image or as an app bundle in an installer. The app bundle
> contains all dependencies, everything, except for the stuff Apple puts
> on the system.  Everything else will not get your application in your
> user's hands.
>
> Any approach that dreams of sharing libraries, configuration locations or
> _any_ other resource not provided by the OS among multiple applications
> will not get that library used by applications that target Windows or OSX.
>
> Now, re-using and re-packaging pre-built dll's _is_ possible. It's
> sometimes, as with fftw3, even the only realistic option. But it would
> still put that dll in the exe dir of every application that uses it. And,
> with complex libraries, it's still not going to work. I use a bunch of
> cmake external projects to build all the deps, so I can cut down on what's
> in there, for instance, and I should cut even more than I'm already doing.
>
> Boudewijn
>
> Ps: there are three ways of packaging an app on Linux: let the distribution
> do it, and fight with your users because they cannot get the latest version,
> package it yourself for each popular distro (in my case, *buntu, CentOS and
> OpenSUSE) or make a distro-independent package, which every big open source
> project does, like Blender or Firefox. In the last case, you'll again have
> to package everything, like on Windows and OSX.
>
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Krfb

[Jeremy Whiting]

Yeah, that's the latest. I e-mailed Urs about krdc and mentioned krfb
also.  He suggested asking for a general review, so that's what this
is now.

thanks,
Jeremy

On Sat, Oct 10, 2015 at 3:26 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El Friday 09 October 2015, a les 10:40:56, Jeremy Whiting va escriure:
>> Hello all,
>>
>> I've ported Krfb to kf5/qt5 on the frameworks branch.
>
>
> Last commit is September 17, did you forget to push some stuff or this is an
> email you wanted to write a while ago?
>
> Cheers,
>   Albert
>
>> It seems to work
>> well here, but I am not the maintainer so thought it would be good if
>> others can take a look at the code also. If one or two people would
>> give it a try I would appreciate it. I'd like to merge frameworks
>> branch to master before the November Applications 15.12 dependency
>> freeze date. Note the following with the port.
>>
>> All telepathy tubes support has been removed since it doesn't work
>> well with existing telepathy protocols anyway after discussing with
>> kde-telepathy maintainers.
>>
>> thanks,
>> Jeremy
>>
>> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>> >> <<
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Review Request 125561: Sync FindGettext.cmake macros with upstream module from CMake

[Jeremy Whiting]

> On Oct. 9, 2015, 2:26 p.m., Albert Astals Cid wrote:
> > This doesn't look like "a bugfix" to me.
> 
> Jeremy Whiting wrote:
> Oh, but it is. Without this or cmake_policy(SET CMP0002 OLD) (see 
> https://bugs.kde.org/show_bug.cgi?id=316308) applications that have their own 
> translations in the tarball (everything we release from extragear) fails to 
> build with a newer cmake. With this change in the kdelibs cmake modules it 
> builds fine by setting a different target for each po folder.
> 
> Albert Astals Cid wrote:
> Ok, bad wording, it's probably a bugfix, but doesn't look like a minimal 
> bugfix, i mean it's rewriting the whole file, is there nothing better than 
> that we can do?

Ah, that I don't know. As I said before, following all this cmake macro stuff 
is somehow over my head (or I'm not trying hard enough, dunno). Hrvoje, is 
there a simpler way to do what you're proposing here?


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125561/#review86580
---


On Oct. 8, 2015, 11:50 a.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125561/
> ---
> 
> (Updated Oct. 8, 2015, 11:50 a.m.)
> 
> 
> Review request for Build System, kdelibs, Localization and Translation 
> (l10n), Albert Astals Cid, and Alexander Neundorf.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Otherwise some apps fail to build with kdelibs >= 4.14.11:
> ```
> CMake Error at /usr/share/kde4/apps/cmake/modules/FindGettext.cmake:232 
> (ADD_CUSTOM_TARGET):
>   add_custom_target cannot create target "pofiles" because another target
>   with the same name already exists.  The existing target is a custom target
>   created in source directory
>   "/home/hrvoje/rpmbuild/BUILD/skanlite-1.1/po/be".  See documentation for
>   policy CMP0002 for more details.
> Call Stack (most recent call first):
>   po/zh_CN/CMakeLists.txt:2 (GETTEXT_PROCESS_PO_FILES)
> ```
> 
> 
> Diffs
> -
> 
>   cmake/modules/FindGettext.cmake 91e88f7 
> 
> Diff: https://git.reviewboard.kde.org/r/125561/diff/
> 
> 
> Testing
> ---
> 
> Skanlite now builds.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

Re: Review Request 125561: Sync FindGettext.cmake macros with upstream module from CMake

[Jeremy Whiting]

> On Oct. 9, 2015, 2:26 p.m., Albert Astals Cid wrote:
> > This doesn't look like "a bugfix" to me.

Oh, but it is. Without this or cmake_policy(SET CMP0002 OLD) (see 
https://bugs.kde.org/show_bug.cgi?id=316308) applications that have their own 
translations in the tarball (everything we release from extragear) fails to 
build with a newer cmake. With this change in the kdelibs cmake modules it 
builds fine by setting a different target for each po folder.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125561/#review86580
---


On Oct. 8, 2015, 11:50 a.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125561/
> ---
> 
> (Updated Oct. 8, 2015, 11:50 a.m.)
> 
> 
> Review request for Build System, kdelibs, Localization and Translation 
> (l10n), Albert Astals Cid, and Alexander Neundorf.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Otherwise some apps fail to build with kdelibs >= 4.14.11:
> ```
> CMake Error at /usr/share/kde4/apps/cmake/modules/FindGettext.cmake:232 
> (ADD_CUSTOM_TARGET):
>   add_custom_target cannot create target "pofiles" because another target
>   with the same name already exists.  The existing target is a custom target
>   created in source directory
>   "/home/hrvoje/rpmbuild/BUILD/skanlite-1.1/po/be".  See documentation for
>   policy CMP0002 for more details.
> Call Stack (most recent call first):
>   po/zh_CN/CMakeLists.txt:2 (GETTEXT_PROCESS_PO_FILES)
> ```
> 
> 
> Diffs
> -
> 
>   cmake/modules/FindGettext.cmake 91e88f7 
> 
> Diff: https://git.reviewboard.kde.org/r/125561/diff/
> 
> 
> Testing
> ---
> 
> Skanlite now builds.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

Krfb

[Jeremy Whiting]

Hello all,

I've ported Krfb to kf5/qt5 on the frameworks branch. It seems to work
well here, but I am not the maintainer so thought it would be good if
others can take a look at the code also. If one or two people would
give it a try I would appreciate it. I'd like to merge frameworks
branch to master before the November Applications 15.12 dependency
freeze date. Note the following with the port.

All telepathy tubes support has been removed since it doesn't work
well with existing telepathy protocols anyway after discussing with
kde-telepathy maintainers.

thanks,
Jeremy

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Review Request 125561: Sync FindGettext.cmake macros with upstream module from CMake

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125561/#review86518
---


Looks good to me, but I can't quite follow it all myself. Someone else should 
give the ship it. If it fixes it so setting the CMake policy 0002 to OLD isn't 
needed anymore that's good.

- Jeremy Whiting


On Oct. 8, 2015, 11:50 a.m., Hrvoje Senjan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125561/
> ---
> 
> (Updated Oct. 8, 2015, 11:50 a.m.)
> 
> 
> Review request for Build System, kdelibs, Localization and Translation 
> (l10n), Albert Astals Cid, and Alexander Neundorf.
> 
> 
> Repository: kdelibs
> 
> 
> Description
> ---
> 
> Otherwise some apps fail to build with kdelibs >= 4.14.11:
> ```
> CMake Error at /usr/share/kde4/apps/cmake/modules/FindGettext.cmake:232 
> (ADD_CUSTOM_TARGET):
>   add_custom_target cannot create target "pofiles" because another target
>   with the same name already exists.  The existing target is a custom target
>   created in source directory
>   "/home/hrvoje/rpmbuild/BUILD/skanlite-1.1/po/be".  See documentation for
>   policy CMP0002 for more details.
> Call Stack (most recent call first):
>   po/zh_CN/CMakeLists.txt:2 (GETTEXT_PROCESS_PO_FILES)
> ```
> 
> 
> Diffs
> -
> 
>   cmake/modules/FindGettext.cmake 91e88f7 
> 
> Diff: https://git.reviewboard.kde.org/r/125561/diff/
> 
> 
> Testing
> ---
> 
> Skanlite now builds.
> 
> 
> Thanks,
> 
> Hrvoje Senjan
> 
>

Filling Holes

[Jeremy Whiting]

Hello everyone.

I'm cross posting to a couple of lists on purpose to hit a bigger audience.

The release team wants you! 

Have you ever thought about what it takes to make KDE software
releases great? Now you can find out first hand. The release team is
in need of some module coordinators as seen here [1]. If you have a
moderate amount of experience with some software we develop step up
and help out. What qualifications are required to become a module
coordinator? Read them there on the techbase page, but mostly these
imo.

 - Don't mind poking stuff in your chosen area to make sure everything builds
 - Watch to make sure nobody breaks stuff in your module
 - Can fix stuff when needed for releases if it is broken for some reason
 - Help shape the future of your chosen module

As you can see it mostly comes down to having time. If you are
interested in any of the spots marked there as "Help Wanted" please
step up and help us continue to make releases awesome.

thanks,
Jeremy

1. https://techbase.kde.org/Projects/Release_Team#Coordinator_List

Review Request 125521: Added KDropWidgetDecorator copied from DropWidget in kile sources. Relicensed from GPL 2+ to LGPL 2+ with author's permission.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125521/
---

Review request for KDE Frameworks and Christoph Feck.


Repository: kwidgetsaddons


Description
---

Added KDropWidgetDecorator copied from DropWidget in kile sources. Relicensed 
from GPL 2+ to LGPL 2+ with author's permission.


Diffs
-

  src/CMakeLists.txt e03e9bbd6d73811873b0a465f86da269f4295138 
  src/kdropwidgetdecorator.h PRE-CREATION 
  src/kdropwidgetdecorator.cpp PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/125521/diff/


Testing
---

It builds, the headers I expect are in the right places, etc. I just noticed 
I'm not exporting the class though, will fix that and reupload.


Thanks,

Jeremy Whiting

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 125521: Added KDropWidgetDecorator copied from DropWidget in kile sources. Relicensed from GPL 2+ to LGPL 2+ with author's permission.

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125521/
---

(Updated Oct. 4, 2015, 1:43 p.m.)


Review request for KDE Frameworks and Christoph Feck.


Changes
---

Added exporting the class.


Repository: kwidgetsaddons


Description
---

Added KDropWidgetDecorator copied from DropWidget in kile sources. Relicensed 
from GPL 2+ to LGPL 2+ with author's permission.


Diffs (updated)
-

  src/CMakeLists.txt e03e9bbd6d73811873b0a465f86da269f4295138 
  src/kdropwidgetdecorator.h PRE-CREATION 
  src/kdropwidgetdecorator.cpp PRE-CREATION 

Diff: https://git.reviewboard.kde.org/r/125521/diff/


Testing
---

It builds, the headers I expect are in the right places, etc. I just noticed 
I'm not exporting the class though, will fix that and reupload.


Thanks,

Jeremy Whiting

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KTabWidget vs QTabWidget

[Jeremy Whiting]

Thanks,

First patch here: https://git.reviewboard.kde.org/r/125521/. After
that I'll try using it in Kile and Okular, see how that goes.

On Thu, Sep 24, 2015 at 11:47 PM, Michel Ludwig <michel.lud...@gmail.com> wrote:
>
> On 09/25/2015 01:57 AM, Jeremy Whiting wrote:
>>
>> Michel,
>>
>> Would you mind if I move the DropWidget you wrote for kile into
>> kwidgetsaddons and give it a name like KDropWidget and relicense it to
>> LGPL v2+ ?
>>
> That's totally fine with me.
>
> Michel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: State of Audio CD support in KDE

[Jeremy Whiting]

Boudhayan,

I think your plan looks good to me. Let me know if I can help in any way.

thanks,
Jeremy

On Tue, Sep 29, 2015 at 6:03 PM, Boudhayan Gupta  wrote:
> Hi Albert (and others),
>
> On 30 September 2015 at 04:09, Albert Astals Cid  wrote:
>>> In terms of support for Audio CDs in KDE,
>>>
>>> * K3B can write them.
>>> * Phonon the API can play them, with some minor but weird bugs.
>>>
>>> And that's it.
>>
>> Does solid offer some support?
>> I guess at least it can say how many drives are there
>> but maybe nothing related to Audio-CD itself?
>
> Solid is interesting. It can detect the number of drives in the
> system, and it can tell us if the CD inside is an Audio CD.
>
> We can also subscribe to signals from Solid that notify is the disc is
> ejected, but there's no signal in Solid::OpticalDrive to notify if a
> new disc was inserted. Maybe it's a small patch that can be worked on?
>
>>> I think we need to take a long hard look at the state of support for
>>> Red Book CDs in KDE and decide:
>>>
>>> a) Do we still want to support them, and
>>> b) If yes, to what degree do we support them?
>>
>> I'd say we totally want to support them. The question is if there's
>> something that can be shared in an library or should it be app specific.
>>
>> The things i can think of doing with an Audio-CD are:
>>
>>  * ripping it
>>  * playing it
>>  * copying it to another Audio-CD
>>
>> Ripping and playing have some "common" stuff that is:
>>  * Finding the CD drive that actually has a Audio-CD inside (if you have 
>> muliple drivers and others
>>are either empty or have data CDs)
>>  * Listing the number of tracks and their info (cddb, or whatever)
>>  * Extracting data to either feed it to the player or ripper
>>
>> So I think that having a library that those these 3 basic things is a good 
>> thing, once we have it we
>> can see how to make it used in kio-audiocd, kaudiocreator, kscd or whatever 
>> cd apps we decide to have.
>>
>> I can't think of a "common" stuff between copying and and ripping/playing.
>
> So here's the situation:
>
> Ripping and playing have some commonality in them, in that they both
> need access to raw PCM data from the disc. Phonon seems to have pretty
> good playback support (I'll file bug reports for the bugs I've been
> mentioning) - so if you have an app that uses Phonon you've got
> support for playing back CDs. Let's not reinvent that wheel, but round
> it out if there are flat spots.
>
> Now information and ripping. KCDDB seems to be in pretty good shape
> (kdelibs4 though) - for getting data about the CD from CDDB servers.
> Whatever work I've done for the libKCompactDisc nextgen branch, I can
> extract raw PCM data from the disc and also read CD-TEXT information
> to find whatever data is embedded in the disc.
>
> kaudiocreator seems to be using CDParanoia directly, as is
> audiocd-kio. I tried to start a basic port of audiocd-kio to kf5
> today, but audiocd-kio is also trying to do too much, because I've
> been looking through the code and it has converters for MP3, FLAC and
> OGG in it.
>
> What I would suggest is:
>
> 1: Let Phonon do the playing
> 2: Let k3b do the copying
> 3: Let Solid do all the disc detection
> 4: Consolidate libKCDDB and libKCompactDisc into an all-in-one
> disc-info and raw-data-from-CD library
> 5: Write a new, very small cdda kioslave that just exposes the audio
> files on the CD as a set of wav files. We can re-use code from the
> current audiocd-kio.
> 6: Once the new lib is up, port KAudioCreator to kf5.
>
> This plan of action will eventually end up removing a lot of lines of
> code and reducing our maintenance burden. Right now:
>
> * kaudiocreator and audiocd-kio both duplicate media conversion code.
> * both use cdparanoia, and do the same thing differently
> * all of them have their own disc detection code
>
> Inputs?
>
> Cheers,
> Boudhayan Gupta

Re: Unable to configure phonon-gstreamer with CMake

[Jeremy Whiting]

kdesrc-build uses a .kdesrc-buildrc file in $HOME or in the current
working directory if found. It also takes command-line arguments like
--stop-on-failure but I thought that wasn't the default. Maybe it has
been set in the .kdesrc-buildrc file in that project? More
documentation can be found here: https://kdesrc-build.kde.org/ and
here: https://kdesrc-build.kde.org/documentation/

Hope that helps,
Jeremy

On Mon, Sep 28, 2015 at 7:52 PM, Jeffrey Brusseau  wrote:
> Yes, it stops the whole thing. I don't know why kdesrc-build doesn't just
> skip over those packages. I'm just using the default setup generated from
> "sudo ./run.py --base archlinux" in this project:
> https://github.com/Wenzel/docker-kdesrc-build and running "sudo
> ./kdesrc-build/kdesrc-build" from inside the container.
>
> Is there perhaps a settings file or flag that determines if kdesrc-build
> skip over optional dependencies or not? If so I'll have to check it out more
> closely.
>
> By the way phonon-gstreamer configures and builds now so that's no longer an
> issue. Now it fails on compiling plasma-nm and that stops the whole thing.
>
> On Mon, Sep 28, 2015 at 2:25 PM, Gregor Mi  wrote:
>>
>> Hi,
>>
>> phonon-gstreamer is one of the few packages that never could be built on
>> my openSUSE 13.2
>> configuration. But normally the rest of the packages will be built anyway.
>> Does the whole
>> build process stop?
>>
>>
>> On 27/09/15 07:06, Jeffrey Brusseau wrote:
>> > I'm trying to set up the KF5 environment in a archlinux base docker
>> > container using the
>> > scripts found here: https://github.com/Wenzel/docker-kdesrc-build
>> >
>> > When I run *sudo ./kdesrc-build/kdesrc-build* (from inside the
>> > container) it fails on
>> > phonon-gstreamer with this output:
>> >
>> > Building phonon-gstreamer from phonon (65/222)
>> > Updating phonon-gstreamer (to branch master)
>> > No source update, but the last configure failed
>> > Source update complete for phonon-gstreamer: no files affected
>> > Preparing build system for phonon-gstreamer.
>> > Removing files in build directory for phonon-gstreamer
>> > Old build system cleaned, starting new build system.
>> > Running cmake...
>> > Unable to configure phonon-gstreamer with CMake!
>> > Unable to configure phonon-gstreamer with KDE
>> > phonon-gstreamer didn't build, stopping here.
>> > Removing 5 out of 6 old log directories...
>> > <<<  PACKAGES FAILED TO BUILD  >>>
>> > phonon-gstreamer -
>> > /work/source/log/2015-09-27-06/phonon-gstreamer/cmake.log
>> > :-(
>> > Your logs are saved in /work/source/log/2015-09-27-06
>> > [kdedev@8e5590b73373 ~]$
>> >
>> >
>> >
>> > This is what's in
>> > //work/source/log/2015-09-27-06/phonon-gstreamer/cmake.log/:
>> >
>> > [kdedev@8e5590b73373 ~]$ cat
>> > /work/source/log/2015-09-27-06/phonon-gstreamer/cmake.log
>> > # kdesrc-build running: 'cmake'
>> > '/work/source/kdesupport/phonon/phonon-gstreamer'
>> > '-DBUILD_TESTING=TRUE' '-DCMAKE_BUILD_TYPE=Debug'
>> > '-DCMAKE_INSTALL_LIBDIR=lib'
>> > '-DLIB_SUFFIX=64' '-DPHONON_BUILD_PHONON4QT5=ON'
>> > '-DCMAKE_CXX_FLAGS:STRING=-pipe
>> > -DQT_STRICT_ITERATORS -DQURL_NO_CAST_FROM_STRING -DQT_NO_HTTP
>> > -DQT_NO_FTP -Wformat
>> > -Werror=return-type -Wno-variadic-macros -Wlogical-op '
>> > '-DCMAKE_INSTALL_PREFIX=/work/install'
>> > # from directory: /work/build/kdesupport/phonon/phonon-gstreamer
>> > -- The C compiler identification is GNU 5.2.0
>> > -- The CXX compiler identification is GNU 5.2.0
>> > -- Check for working C compiler: /usr/bin/cc
>> > -- Check for working C compiler: /usr/bin/cc -- works
>> > -- Detecting C compiler ABI info
>> > -- Detecting C compiler ABI info - done
>> > -- Detecting C compile features
>> > -- Detecting C compile features - done
>> > -- Check for working CXX compiler: /usr/bin/c++
>> > -- Check for working CXX compiler: /usr/bin/c++ -- works
>> > -- Detecting CXX compiler ABI info
>> > -- Detecting CXX compiler ABI info - done
>> > -- Detecting CXX compile features
>> > -- Detecting CXX compile features - done
>> > -- Looking for __GLIBC__
>> > -- Looking for __GLIBC__ - found
>> > -- Performing Test _OFFT_IS_64BIT
>> > -- Performing Test _OFFT_IS_64BIT - Success
>> > -- Using CMake automoc builtin
>> > -- Found Phonon4Qt5: /work/install/lib/cmake/phonon4qt5
>> > -- Found OpenGL: /usr/lib64/libGL.so
>> > -- Found PkgConfig: /usr/bin/pkg-config (found version "0.28")
>> > -- checking for module 'gstreamer-1.0'
>> > --   found gstreamer-1.0, version 1.4.5
>> > -- Found GStreamer: /usr/lib64/libgstreamer-1.0.so
>> > 
>> > -- checking for module 'gstreamer-plugins-base-1.0'
>> > --   found gstreamer-plugins-base-1.0, version 1.4.5
>> > -- checking for module 'gstreamer-audio-1.0'
>> > -- 

Re: Cervisia?

[Jeremy Whiting]

Martin,

Michael Reeves reeves...@gmail.com mentioned he would be interested in
helping also, maybe the two of you can get it ported away from
Qt3Support, then ported to Qt5/Kf5 ?

thanks,
Jeremy

On Sat, Sep 26, 2015 at 3:55 PM, Martin Koller <kol...@aon.at> wrote:
> On Monday 14 September 2015 13:59:20 Jeremy Whiting wrote:
>> Well, it was released as part of Applications 15.08.0 (and will be in
>> the rest of the .x releases) I'm fine either way, but it seems like
>> continuing to release something that hasn't been looked at in quite
>> some time. I think to continue to release it we would need to have:
>>
>> 1) A port to Qt5/KF5 which could be difficult with Qt3Support stuff in
>> it, tricky but doable.
>> 2) A maintainer.
>>
>> Anyone want to try taking on one or both of those?
>
> As I still use cervisia daily, I can't let it go to /dev/null ...
> I started to port away from Q3 classes, so the next step to port to KF5 is 
> easier.
> No promises though, since my day job is demanding
>
> --
> Best regards/Schöne Grüße
>
> Martin
> A: Because it breaks the logical sequence of discussion
> Q: Why is top posting bad?
>
> ()  ascii ribbon campaign - against html e-mail
> /\- against proprietary attachments
>
> Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Jeremy Whiting]

And to make sure you get concensus before releasing something that
uses or implements the interface.


On Fri, Sep 25, 2015 at 9:02 AM, Martin Klapetek
 wrote:
> On Fri, Sep 25, 2015 at 10:54 AM, Boudhayan Gupta  wrote:
>>
>>
>> In other *unrelated* news, I've woken up to certain disaster on the
>> dbus mailing list, so for now I'll move it to the org.kde namespace.
>
>
> It's not a disaster, people are just telling you "think the interface
> through
> and then propose it on a correct list (xdg), not on dbus list". Far from
> disaster :P
>
> Cheers
> --
> Martin Klapetek | KDE Developer

Re: Spectacle moved to KDE Graphics, future of KSnapshot?

[Jeremy Whiting]

Hello,

On Thu, Sep 24, 2015 at 4:11 AM, Boudhayan Gupta  wrote:
> Hi all,
>
> Spectacle has been moved to KDE Graphics.
>
> There are a few things that need to be done for a smooth release with
> Applications 15.12. I'll list them below:
>
> 1. Inclusion into the list of applications released as part of KDE
> Applications. I believe I'll have to trouble Albert for that?

A mail to the release-team mailing list would be nice, but it's ok I
added spectacle to the list of modules for Applications 15.12.

> 2. Icon. I've filed a Breeze bug at
> https://bugs.kde.org/show_bug.cgi?id=353126 to symlink the ksnapshot
> icon to spectacle. Should I do the same for Oxygen?
>
> 3. KHotkeys. Once Spectacle is included into Applications 15.12, I'll
> patch KHotkeys to look for Spectacle rather than KSnapshot.
>
> Now, what'll come of KSnapshot? Spectacle clearly obsoletes KSnapshot
> on X11 (and Wayland as long as KWin is running - if a generic Wayland
> protocol isn't out by dependency freeze I'll add a generic KWin
> backend temporarily for this release). However, we have no Mac OS and
> Windows backends, so KSnapshot clearly still has use in those
> platforms.
>
> What about moving KSnapshot to Extragear?

If this is what we end up deciding it needs to be decided before Nov
11 which is the KDE Applications 15.12 dependency freeze date. Let us
know on the release team mailing list so we can remove it from the
list of modules if so.

thanks,
Jeremy

> Cheers,
> Boudhayan Gupta

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[Jeremy Whiting]

That does sound like a bit more interesting question. Browsing through
http://lxr.kde.org/ident?_i=QStandardPaths&_remember=1 (quite a long
list...) a couple of things come to mind. First anything that's using
QStandardPaths isn't necessarily using any frameworks at all. Looking
at http://agateau.com/2013/kf5-diagrams/kf5.png (which admittedly may
not be up to date either) it seems KCoreAddons is a very commonly used
framework. Also depended on by many other frameworks and used by many
applications. It contains KAboutData which is used by pretty much any
GUI application that we release, I'm not sure if it matters if it
needs to be used by command-line tools also or not. I'm not sure how
many if any command line tools or system daemons etc. are using
QStandardPaths. Maybe try with KCoreAddons and see if that's a
suitable enough place?

BR,
Jeremy

On Thu, Sep 24, 2015 at 3:34 AM, René J.V.  wrote:
> In fact, let me ask a different question: is there a KF5 framework that is 
> guaranteed to be linked to by all KF5 applications that have reason (or are 
> likely) to query QStandardPaths for locations?
> That would probably provide the cleanest and easiest solution to my quest: 
> that framework could be patched (on OS X or for MacPorts/Fink/...) to 
> activate the QSP mode switch. (And that could be either using an instance of 
> the dedicated class I described, or using an OS X framework initialisation 
> routine.)
>
> R.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KNotifications filters

[Jeremy Whiting]

Hey all,

I've discussed this a bit with Eike previously, but thought I'd try a
wider audience to get some more ideas. When we used to have
kttsd/jovie it had the concept of filters that it would use for
different applications speech to normalize what gets sent to the
synthesizer. In this way notifications from
kopete/konversation/whatever would be changed from:

'milian PovAddict: why are you not here!'

to

Milian says: PovAddict: why are you not here!

The Jovie git repository has some default filters that can be used for
chat, chat-de, kmail, polish, qt2plaintext etc. that were useful for
users to load that would do the filtering. I think this feature was
very very hard to find though. Anyway, Jovie is dying, and I'd like to
bring this feature back to all speech that goes through KNotifications
to QtSpeech. KNotifications has src/notifybytts which sends
notification text, or appname, or can even send eventId to QtSpeech,
but I'd like to add filtering here. I think we should probably default
to filtering with all sane filters but make them customizable of
course in case anyone wants to tweak them. The problem is that
KNotifications pass a KNotifyConfig for each notification, so each
application's notifications have their own config for TTS entry.
Should/could we use one global configuration for all filters and load
it in NotifyByTTS::notify so all notifications are filtered the same
way? If so I guess the logical place for it would be a TTS group in
kdeglobals, does that make sense?

thanks,
Jeremy
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KTabWidget vs QTabWidget

[Jeremy Whiting]

Yes, the two authors of that code are Michel Ludwig and Andreas
Cord-Landwehr who both are listed in relicensecheck.pl as giving
permission to change to lgpl+ So I think we should be fine to
move/copy that in and start using it in stead of the copy in kile.

On Tue, Sep 22, 2015 at 3:45 PM, Luigi Toscano <luigi.tosc...@tiscali.it> wrote:
> Jeremy Whiting ha scritto:
>> In looking at what is using KTabWidget it seems there's a drop in
>> replacement for what we are doing in
>> http://lxr.kde.org/source/extragear/office/kile/src/kileviewmanager.h
>> in DropWidget towards the bottom. Could/should we simply copy that to
>> kwidgetsaddons and rename it KDropWidgetDecorator and use it where old
>> code was using KTabWidget?
>
> If license or relicensing allow...
>
> Ciao
> --
> Luigi
>
> ___
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel@kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: [KDE/Mac] [OS X] adding a link module to all KF5 targets

[Jeremy Whiting]

Rene,

Back to your original question I don't think there is such a place,
besides patching QtCore itself. Many of the frameworks and
applications use KI18n, but some don't I don't think there's a common
location that every application linking against KF5 libraries uses.

BR,
Jeremy


On Wed, Sep 23, 2015 at 3:15 AM, René J.V.  wrote:
> Let me just add what me me come to KDE.
> That was mostly out of unhappiness with changes in OS X applications and 
> development, and to find replacements for mail and IDE applications (and 
> because I'd seen on Linux that KDE4 was about ripe to be an alternative to 
> the OS X GUI, I was both blissfully and sadly unaware of KF5).
> I also use digiKam and KDEnlive but my main applications are Kontact and 
> KDevelop. I could see myself use Karbon at some point when my PPC copy of 
> Illustrator really no longer cuts it, but for the rest I find myself reaching 
> for my older copy of Pages (and Numbers & Keynote) from back when Apple still 
> hadn't ripped out the interesting functionality, and to image processing 
> applications built purely on native APIs.
>
> Maybe this helps put my priorities in perspective ... and now, back to the 
> original question please!
>
> R.
> ___
> kde-...@kde.org
> List Information: https://mail.kde.org/mailman/listinfo/kde-mac
> KDE/Mac Information: http://community.kde.org/Mac
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KTabWidget vs QTabWidget

[Jeremy Whiting]

In looking at what is using KTabWidget it seems there's a drop in
replacement for what we are doing in
http://lxr.kde.org/source/extragear/office/kile/src/kileviewmanager.h
in DropWidget towards the bottom. Could/should we simply copy that to
kwidgetsaddons and rename it KDropWidgetDecorator and use it where old
code was using KTabWidget?

BR,
Jeremy

On Tue, Sep 22, 2015 at 12:47 AM, David Faure <fa...@kde.org> wrote:
> On Monday 21 September 2015 20:16:01 Jeremy Whiting wrote:
>> David,
>>
>> I've been considering what you mean. I think I understand, but wanted
>> to check before I spend a bit of time trying to implement what you
>> described. Does the class below fit what you are considering?
>>
>> class KDropWidgetDecorator: public QObject {
>> Q_OBJECT
>>  public:
>>   void installEventFilter(QWidget *);
>
> installEventFilter is an existing QObject method, better just do it
> in the KDropWidgetDecorator constructor.
>
>>  signals:
>> void receivedDropEvent (QDropEvent *);
>> void testCanDecode (const QDragMoveEvent *e, bool );
>
> non-const refs in signals are an ugly hack.
> You don't know if there is going to be 0, 1 or N slots, and the ref only 
> makes sense for 1.
>
> Instead I suggest:
> * a virtual method, but that means deriving from the decorator, not great
> * a virtual method in a separate interface class (so you can just make your
> main widget implement that interface)
> * a std::function, so the caller can pass a lambda or a static function
>
> Alternatively, call it KUrlDropWidgetDecorator and make it support urls
> out of the box. This is the most common use case all over KDE, isn't it?
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: KTabWidget vs QTabWidget

[Jeremy Whiting]

David,

I've been considering what you mean. I think I understand, but wanted
to check before I spend a bit of time trying to implement what you
described. Does the class below fit what you are considering?

class KDropWidgetDecorator: public QObject {
Q_OBJECT
 public:
  void installEventFilter(QWidget *);
 signals:
void receivedDropEvent (QDropEvent *);
void testCanDecode (const QDragMoveEvent *e, bool );
};

then in the eventFilter function it would emit the old signals
accordingly and the slots connected to them can handle the QDropEvent
or QDragMoveEvent and such like they used to in KDELibs4 times.

BR,
Jeremy


On Sat, Sep 19, 2015 at 8:49 AM, David Faure <fa...@kde.org> wrote:
> On Friday 18 September 2015 18:46:24 Jeremy Whiting wrote:
>> Hey all,
>>
>> In looking into fixing the remaining issues in Okular's frameworks
>> branch I realized that in part of the effort to port it away from
>> KDELibs4Support it got some functionality removed. It was ported from
>> KTabWidget to QTabWidget but QTabWidget doesn't seem to support drag
>> and drop the way KTabWidget did. In looking at the KTabWidget
>> documentation on api.kde.org it still says that KTabWidget is
>> preferred over QTabWidget [1]. If that's the case why did it end up in
>> KDELibs4Support?
>
> Nobody took the time to update the documentation of all the classes
> that were moved to kdelibs4support.
> So as always: trust the code more than the documentation.
>
>> In reading Qt documentation about drag and drop [2] it seems that you
>> need to subclass widgets in order to specify any additional mime types
>> that should be handled by a drop event (which okular made use of so
>> you could drop documents on it's tab bar to open them). Without
>> KTabWidget we lose that feature completely unless we subclass
>> QTabWidget (which we have in KTabWidget... so why not just use it...).
>> Am I missing something? If not I suggest we reconsider and maybe
>> move/copy? KTabWidget into KF5::WidgetsAddons as it still provides
>> functionality we want/need in some cases. I'm not sure what would be
>> BC or SC in this case tbh (or maybe users of KTabWidget should just
>> keep using KDELibs4Support?)
>
> To be clear: QTabWidget supports dnd-to-reorder tabs, but that's not
> what you're after, you want DnD of URLs, right?
>
> It takes about 10 lines of code in a QTabWidget subclass, but of course
> I have no objection to this being provided by KF5 for convenience.
> However, *not* as a QTabWidget subclass then. We moved away from that design
> because it creates confusion (when to use QTabWidget and when to use 
> KTabWidget)
> and makes things less flexible. Instead, I suggest that you want a decorator,
> much like KDragWidgetDecorator in kwidgetaddons, but for drops of URLs.
> The decorator would install event filters for DragEnter and Drop, check for 
> URLs,
> decode on drop, emit a signal. The only problem is: how would we tell the 
> decorator
> that we only want drops "in the empty area next to the tabbar" and not 
> everywhere
> on the tabwidget... (I assume this is what you want, right?).
>
> (I'm keeping the CC to kde-core-devel so its readers can see this has been
> answered, but I suggest we now followup on kde-frameworks-devel only).
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Volunteer developer without much experience

[Jeremy Whiting]

Hello Oleg,

There's an unofficial list here
http://developer.kde.org/~cfeck/portingstatus.html of which
applications still need some help to get ported to Qt5/KF5. If you
have questions fele free to ask here or on irc in #kde-devel on
freenode.

BR,
Jeremy

On Sun, Sep 20, 2015 at 11:16 AM, Oleg Kitain  wrote:
> Hello Kevin,
> 20.09.2015 19:15, Kevin Krammer пишет:
>>
>> Hi Oleg,
>>
>> On Sunday, 2015-09-20, 14:23:07, Oleg Kitain wrote:
>>>
>>> Hello KDE people.
>>> I'm a developer at ELVEES-NeoTek who, so far, has mostly worked with
>>> drivers and Python applications.
>>> I don't currently have Qt experience, but I am fairly competent in C and
>>> pretty okay with C++.
>>>
>>> I want to help KDE5 achieve feature parity with KDE4. How can I start?
>>
>> Any particular product of KDE you want to work on?
>> The shell/desktop, or one of the applications?
>>
>> Cheers,
>> Kevin
>>
> I feel like an application would be an easier start for me. I, however,
> don't know which ones actually need help, much less help from someone not
> yet well-versed in KDE infrastructure. The player application, maybe? Or
> Kid3? Or K3B?
>
> --
> Cheers,
> Helga/Oleg Kitain
>
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Volunteer developer without much experience

[Jeremy Whiting]

If there's a branch name, then that's the branch where the porting
effort is taking place. The columns show the status of the porting
effort (whether it is on a branch or on master doesn't matter). We
release what's in master though, so for Applications 15.12 to have the
port of these applications the frameworks or kf5 or whatnot branches
will need to be merged to master before Applications 15.12 dependency
freeze which is Thursday November 11th.

BR,
Jeremy

On Sun, Sep 20, 2015 at 2:10 PM, R.Harish Navnit <harishnav...@gmail.com> wrote:
> Uhm, sorry to gatecrash.
>
> On Mon, Sep 21, 2015 at 12:00 AM, Jeremy Whiting <jpwhit...@kde.org> wrote:
>>
>>
>> There's an unofficial list here
>> http://developer.kde.org/~cfeck/portingstatus.html of which
>> applications still need some help to get ported to Qt5/KF5.
>
> Just wanted to know what exactly are those columns specifying ? From what I
> understand, the branch on which some porting work has been initiated is
> shown(written) and the other columns show certain milestones(?) on the
> porting process(hovering over them suggests me this) or are they different
> branches which are also being ported ?
>
> Thanks,
> R.Harish Navnit
> The Enigma
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

KTabWidget vs QTabWidget

[Jeremy Whiting]

Hey all,

In looking into fixing the remaining issues in Okular's frameworks
branch I realized that in part of the effort to port it away from
KDELibs4Support it got some functionality removed. It was ported from
KTabWidget to QTabWidget but QTabWidget doesn't seem to support drag
and drop the way KTabWidget did. In looking at the KTabWidget
documentation on api.kde.org it still says that KTabWidget is
preferred over QTabWidget [1]. If that's the case why did it end up in
KDELibs4Support?

In reading Qt documentation about drag and drop [2] it seems that you
need to subclass widgets in order to specify any additional mime types
that should be handled by a drop event (which okular made use of so
you could drop documents on it's tab bar to open them). Without
KTabWidget we lose that feature completely unless we subclass
QTabWidget (which we have in KTabWidget... so why not just use it...).
Am I missing something? If not I suggest we reconsider and maybe
move/copy? KTabWidget into KF5::WidgetsAddons as it still provides
functionality we want/need in some cases. I'm not sure what would be
BC or SC in this case tbh (or maybe users of KTabWidget should just
keep using KDELibs4Support?)

BR,
Jeremy


1. 
http://api.kde.org/frameworks-api/frameworks5-apidocs/kdelibs4support/html/classKTabWidget.html
2. http://doc.qt.io/qt-5/dnd.html
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KTabWidget vs QTabWidget

[Jeremy Whiting]

Hey all,

In looking into fixing the remaining issues in Okular's frameworks
branch I realized that in part of the effort to port it away from
KDELibs4Support it got some functionality removed. It was ported from
KTabWidget to QTabWidget but QTabWidget doesn't seem to support drag
and drop the way KTabWidget did. In looking at the KTabWidget
documentation on api.kde.org it still says that KTabWidget is
preferred over QTabWidget [1]. If that's the case why did it end up in
KDELibs4Support?

In reading Qt documentation about drag and drop [2] it seems that you
need to subclass widgets in order to specify any additional mime types
that should be handled by a drop event (which okular made use of so
you could drop documents on it's tab bar to open them). Without
KTabWidget we lose that feature completely unless we subclass
QTabWidget (which we have in KTabWidget... so why not just use it...).
Am I missing something? If not I suggest we reconsider and maybe
move/copy? KTabWidget into KF5::WidgetsAddons as it still provides
functionality we want/need in some cases. I'm not sure what would be
BC or SC in this case tbh (or maybe users of KTabWidget should just
keep using KDELibs4Support?)

BR,
Jeremy


1. 
http://api.kde.org/frameworks-api/frameworks5-apidocs/kdelibs4support/html/classKTabWidget.html
2. http://doc.qt.io/qt-5/dnd.html

Re: Review Request 125297: okular: Change Shell::openDocument parameter from QUrl to QString so it can be called via DBus

[Jeremy Whiting]

> On Sept. 17, 2015, 3:28 p.m., Thomas Lübking wrote:
> > a) fix the test?
> > b) the patch first limits to a Url subset and then guesses what it was ... 
> > if that is the "fix" it smell like okular or the test scenario cannot deal 
> > with remote files?

As I said in the description this isn't meant to fix the test, but to remove 
another warning. The warning states that openDocument is ignored because QUrl 
isn't a type registered with QtDBus. I agree and am not sure why this function 
was changed from taking a QString url over DBus to trying (and failing) to take 
a QUrl instead since QDBus doesn't know what QUrl even is.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125297/#review85590
---


On Sept. 17, 2015, 3:06 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125297/
> ---
> 
> (Updated Sept. 17, 2015, 3:06 p.m.)
> 
> 
> Review request for kdelibs and Albert Astals Cid.
> 
> 
> Repository: okular
> 
> 
> Description
> ---
> 
> When running the mainshelltest the tests that fail report being unable to 
> call openDocument because of it's QUrl parameter. With this it no longer 
> complains about that (but the tests still fail).
> 
> 
> Diffs
> -
> 
>   shell/okular_main.cpp 1c988d9 
>   shell/shell.h c16a0b2 
>   shell/shell.cpp d0204f9 
> 
> Diff: https://git.reviewboard.kde.org/r/125297/diff/
> 
> 
> Testing
> ---
> 
> Test no longer complains about being unable to call openDocument.
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

Re: Review Request 125297: okular: Change Shell::openDocument parameter from QUrl to QString so it can be called via DBus

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125297/
---

(Updated Sept. 17, 2015, 3:46 p.m.)


Review request for kdelibs and Albert Astals Cid.


Changes
---

Fixed issues pointed out by Thomas.


Repository: okular


Description
---

When running the mainshelltest the tests that fail report being unable to call 
openDocument because of it's QUrl parameter. With this it no longer complains 
about that (but the tests still fail).


Diffs (updated)
-

  shell/okular_main.cpp 1c988d9 
  shell/shell.h c16a0b2 
  shell/shell.cpp d0204f9 

Diff: https://git.reviewboard.kde.org/r/125297/diff/


Testing
---

Test no longer complains about being unable to call openDocument.


Thanks,

Jeremy Whiting

Re: Review Request 125297: okular: Change Shell::openDocument parameter from QUrl to QString so it can be called via DBus

[Jeremy Whiting]

> On Sept. 17, 2015, 4:17 p.m., Albert Astals Cid wrote:
> > shell/shell.cpp, line 99
> > <https://git.reviewboard.kde.org/r/125297/diff/3/?file=404615#file404615line99>
> >
> > I'd actually prefer if you fixed DnD as the fixme says instead of 
> > removing the feature.

Dragging and dropping of tabs is working fine with QTabBar as is.


- Jeremy


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125297/#review85593
---


On Sept. 17, 2015, 3:46 p.m., Jeremy Whiting wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125297/
> ---
> 
> (Updated Sept. 17, 2015, 3:46 p.m.)
> 
> 
> Review request for kdelibs and Albert Astals Cid.
> 
> 
> Repository: okular
> 
> 
> Description
> ---
> 
> When running the mainshelltest the tests that fail report being unable to 
> call openDocument because of it's QUrl parameter. With this it no longer 
> complains about that (but the tests still fail).
> 
> 
> Diffs
> -
> 
>   shell/okular_main.cpp 1c988d9 
>   shell/shell.h c16a0b2 
>   shell/shell.cpp d0204f9 
> 
> Diff: https://git.reviewboard.kde.org/r/125297/diff/
> 
> 
> Testing
> ---
> 
> Test no longer complains about being unable to call openDocument.
> 
> 
> Thanks,
> 
> Jeremy Whiting
> 
>

Review Request 125297: okular: Change Shell::openDocument parameter from QUrl to QString so it can be called via DBus

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125297/
---

Review request for kdelibs and Albert Astals Cid.


Repository: okular


Description
---

When running the mainshelltest the tests that fail report being unable to call 
openDocument because of it's QUrl parameter. With this it no longer complains 
about that (but the tests still fail).


Diffs
-

  shell/okular_main.cpp 1c988d9 
  shell/shell.h c16a0b2 
  shell/shell.cpp d0204f9 

Diff: https://git.reviewboard.kde.org/r/125297/diff/


Testing
---

Test no longer complains about being unable to call openDocument.


Thanks,

Jeremy Whiting

Re: Review Request 125297: okular: Change Shell::openDocument parameter from QUrl to QString so it can be called via DBus

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125297/
---

(Updated Sept. 17, 2015, 3:06 p.m.)


Review request for kdelibs and Albert Astals Cid.


Changes
---

Remove unused KTabWidget slots instead of commenting out the connect only.


Repository: okular


Description
---

When running the mainshelltest the tests that fail report being unable to call 
openDocument because of it's QUrl parameter. With this it no longer complains 
about that (but the tests still fail).


Diffs (updated)
-

  shell/okular_main.cpp 1c988d9 
  shell/shell.h c16a0b2 
  shell/shell.cpp d0204f9 

Diff: https://git.reviewboard.kde.org/r/125297/diff/


Testing
---

Test no longer complains about being unable to call openDocument.


Thanks,

Jeremy Whiting

Re: Review Request 125297: okular: Change Shell::openDocument parameter from QUrl to QString so it can be called via DBus

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125297/
---

(Updated Sept. 17, 2015, 4:58 p.m.)


Status
--

This change has been discarded.


Review request for kdelibs and Albert Astals Cid.


Repository: okular


Description
---

When running the mainshelltest the tests that fail report being unable to call 
openDocument because of it's QUrl parameter. With this it no longer complains 
about that (but the tests still fail).


Diffs
-

  shell/okular_main.cpp 1c988d9 
  shell/shell.h c16a0b2 
  shell/shell.cpp d0204f9 

Diff: https://git.reviewboard.kde.org/r/125297/diff/


Testing
---

Test no longer complains about being unable to call openDocument.


Thanks,

Jeremy Whiting

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

"I've let it there as a testimony of the dark side of wikis." <-- me
adds that to his quote book.

As a brand new user of KDE Connect if we had a user manual I would
look in it to see why for some reason the connection between KDE
Connect and my android phone who's name is "Jeremy's LG Phone" is for
some reason "Ige" or even better how to change it to something
meaningful.

BR,
Jeremy


On Tue, Sep 15, 2015 at 3:17 PM, Albert Astals Cid  wrote:
> El Dimarts, 15 de setembre de 2015, a les 08:01:44, Albert Vaca va escriure:
>> I don't think that having "descriptive documentation" (more about this
>> later) is that important nowadays, and IMO users will likely google for
>> help way before they use the help button when they find issues. Since most
>> people I talked to in Randa agreed with me on this, I'm a bit surprised to
>> find that you want to enforce this as a strong requirement.
>
> He doesn't want to enforce this as a strong requirement. It is just another of
> the requirement listed on our list of requirements.
>
>> IMO, the kind of documentation that users need is not a list of every
>> button in the KCM with a redundant description like the one we provide
>> (probably because most projects write it just to meet the requirement), but
>> instead answers to questions like "I see error X, what to do?". And this
>> kind of help is easier to find online, in wikis, forums, etc. than in the
>> static documentation we provide.
>
> People need both, documentation that drives them through the crucial/hard
> parts of the UI and support forums for when something goes wrong, they're not
> exclusive.
>
>> Leaving aside the utility of having docs, they are yet another moving piece
>> to maintain and likely to become outdated (eg: "Activity Settings" help
>> shows a screenshot from KDE 4), specially in a piece of software in change
>> like KDE Connect.
>
> What makes KDE Connect special?
>
>> To put an example of a similar case, Windows 10 completely removed the
>> "Help Center" and now it sends you online to the MS site if you need help.
>
> Meaning you're screwed if you don't have internet access \o/
>
>> Why don't we move our docs to the userbase wiki, and make it an open and
>> live thing that users can update (ala Arch Linux wiki)? If there are no
>> objections, I could start a page for KDE Connect there and make the help
>> button in the KCM link to it. Also, since right now we don't have any
>> numbers around how many poeple uses our help, moving it to the web would
>> give us some nice analytics around it for free.
>
> Because as well as the internet being awesome it also sucks, if you go to
> https://userbase.kde.org/Okular [1] we recommed removing ~/.cups/lpoptions if
> you have problems printing, sure it says "the file was corrupt", but how many
> of our users are able to diferentiate a corrupt lpoptions from a non corrupt
> one (i can't)?
>
> I've let it there as a testimony of the dark side of wikis.
>
> Cheers,
>   Albert
>
> [1] a page that has less content and is generally worse than
> https://okular.kde.org/ that i still don't understand why we need, but that's
> a discussion for a different day
>
>>
>> Albert
>

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

I see your points and actually agree. I'm completely ok with having
help go to some online documentation on userbase. I see the
requirement for offline/included help documentation to be going down
lately as you say and completely moot for kdeconnect since it
technically requires an internet connection anyway.

Thanks for explaining the reasoning.

BR,
Jeremy

On Tue, Sep 15, 2015 at 9:01 AM, Albert Vaca  wrote:
> I don't think that having "descriptive documentation" (more about this
> later) is that important nowadays, and IMO users will likely google for help
> way before they use the help button when they find issues. Since most people
> I talked to in Randa agreed with me on this, I'm a bit surprised to find
> that you want to enforce this as a strong requirement. I can of course write
> a few lines to meet this requirement, but I would like to start a discussion
> to re-think why we are doing this.
>
> IMO, the kind of documentation that users need is not a list of every button
> in the KCM with a redundant description like the one we provide (probably
> because most projects write it just to meet the requirement), but instead
> answers to questions like "I see error X, what to do?". And this kind of
> help is easier to find online, in wikis, forums, etc. than in the static
> documentation we provide.
>
> Leaving aside the utility of having docs, they are yet another moving piece
> to maintain and likely to become outdated (eg: "Activity Settings" help
> shows a screenshot from KDE 4), specially in a piece of software in change
> like KDE Connect.
>
> To put an example of a similar case, Windows 10 completely removed the "Help
> Center" and now it sends you online to the MS site if you need help.
>
> Why don't we move our docs to the userbase wiki, and make it an open and
> live thing that users can update (ala Arch Linux wiki)? If there are no
> objections, I could start a page for KDE Connect there and make the help
> button in the KCM link to it. Also, since right now we don't have any
> numbers around how many poeple uses our help, moving it to the web would
> give us some nice analytics around it for free.
>
> Albert

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

I see your points and actually agree. I'm completely ok with having
help go to some online documentation on userbase. I see the
requirement for offline/included help documentation to be going down
lately as you say and completely moot for kdeconnect since it
technically requires an internet connection anyway.

Thanks for explaining the reasoning.

BR,
Jeremy

On Tue, Sep 15, 2015 at 9:01 AM, Albert Vaca  wrote:
> I don't think that having "descriptive documentation" (more about this
> later) is that important nowadays, and IMO users will likely google for help
> way before they use the help button when they find issues. Since most people
> I talked to in Randa agreed with me on this, I'm a bit surprised to find
> that you want to enforce this as a strong requirement. I can of course write
> a few lines to meet this requirement, but I would like to start a discussion
> to re-think why we are doing this.
>
> IMO, the kind of documentation that users need is not a list of every button
> in the KCM with a redundant description like the one we provide (probably
> because most projects write it just to meet the requirement), but instead
> answers to questions like "I see error X, what to do?". And this kind of
> help is easier to find online, in wikis, forums, etc. than in the static
> documentation we provide.
>
> Leaving aside the utility of having docs, they are yet another moving piece
> to maintain and likely to become outdated (eg: "Activity Settings" help
> shows a screenshot from KDE 4), specially in a piece of software in change
> like KDE Connect.
>
> To put an example of a similar case, Windows 10 completely removed the "Help
> Center" and now it sends you online to the MS site if you need help.
>
> Why don't we move our docs to the userbase wiki, and make it an open and
> live thing that users can update (ala Arch Linux wiki)? If there are no
> objections, I could start a page for KDE Connect there and make the help
> button in the KCM link to it. Also, since right now we don't have any
> numbers around how many poeple uses our help, moving it to the web would
> give us some nice analytics around it for free.
>
> Albert

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

Aleix,

I disagree. I see the colors kcm has a manual, the icons kcm has a
manual, both accessible from the big "Help" button on the kcm in
systemsettings. kdeconnect's kcm has a Help button disabled because
there's no manual. While the ui is pretty intuitive, it would be good
to have something to show when users hit the "Help" button that says
what each option does at a minimum. It doesn't need to be much, but
something is better than nothing in my opinion.

BR,
Jeremy

On Mon, Sep 14, 2015 at 6:13 PM, Aleix Pol <aleix...@kde.org> wrote:
> On Mon, Sep 14, 2015 at 12:52 AM, Jeremy Whiting <jpwhit...@kde.org> wrote:
>> As shown here: http://developer.kde.org/~cfeck/portingstatus.html
>> (under Extragear base) It is missing a manual. Needs a Feature_summary
>> added to CMakeLists.txt and some .desktop files should be renamed to
>> org.kde.foo.desktop.
>>
>> I just tried it out and it seems to work here, though I'm not seeing
>> sms notifications in the desktop like I expected (I am able to control
>> cantata from my phone though, which is handy). Yes I installed the
>> beta on the play store.
>>
>> BR,
>> Jeremy
>>
>>
>> On Sat, Sep 12, 2015 at 6:29 AM, Albert Vaca <albertv...@gmail.com> wrote:
>>>> I moved the translations for both repositories. Please update the
>>>> translations
>>>> branches for kdeconnect-android so that trunk_kf5 is master and trunk is
>>>> none;
>>>> yes, it's android and it does not matter, but it's easier for us.
>>>
>>>
>>> Done.
>>>
>>>>
>>>> Translation branches for kdeconnect-kde are fine (translations moved few
>>>> months ago). In addition to master, we track also the 'kde4' branch. Do
>>>> you
>>>> plan to release additional versions from there, or can we drop that
>>>> branch?
>>>
>>>
>>> Removed kde4.
>>>
>
> Hi Jeremy,
> We just fixed the desktop naming issue and added the feature summary.
>
> Regarding the documentation, we discussed it briefly during the sprint
> and we have the feeling that the documentation for such a project
> would look more like a simple placeholder or something easily outdated
> than anything. Furthermore, since there isn't a clear main window of
> the application, it would be unintuitive to get there. We're convinced
> nobody would ever end up there.
>
> Aleix

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

Aleix,

I disagree. I see the colors kcm has a manual, the icons kcm has a
manual, both accessible from the big "Help" button on the kcm in
systemsettings. kdeconnect's kcm has a Help button disabled because
there's no manual. While the ui is pretty intuitive, it would be good
to have something to show when users hit the "Help" button that says
what each option does at a minimum. It doesn't need to be much, but
something is better than nothing in my opinion.

BR,
Jeremy

On Mon, Sep 14, 2015 at 6:13 PM, Aleix Pol <aleix...@kde.org> wrote:
> On Mon, Sep 14, 2015 at 12:52 AM, Jeremy Whiting <jpwhit...@kde.org> wrote:
>> As shown here: http://developer.kde.org/~cfeck/portingstatus.html
>> (under Extragear base) It is missing a manual. Needs a Feature_summary
>> added to CMakeLists.txt and some .desktop files should be renamed to
>> org.kde.foo.desktop.
>>
>> I just tried it out and it seems to work here, though I'm not seeing
>> sms notifications in the desktop like I expected (I am able to control
>> cantata from my phone though, which is handy). Yes I installed the
>> beta on the play store.
>>
>> BR,
>> Jeremy
>>
>>
>> On Sat, Sep 12, 2015 at 6:29 AM, Albert Vaca <albertv...@gmail.com> wrote:
>>>> I moved the translations for both repositories. Please update the
>>>> translations
>>>> branches for kdeconnect-android so that trunk_kf5 is master and trunk is
>>>> none;
>>>> yes, it's android and it does not matter, but it's easier for us.
>>>
>>>
>>> Done.
>>>
>>>>
>>>> Translation branches for kdeconnect-kde are fine (translations moved few
>>>> months ago). In addition to master, we track also the 'kde4' branch. Do
>>>> you
>>>> plan to release additional versions from there, or can we drop that
>>>> branch?
>>>
>>>
>>> Removed kde4.
>>>
>
> Hi Jeremy,
> We just fixed the desktop naming issue and added the feature summary.
>
> Regarding the documentation, we discussed it briefly during the sprint
> and we have the feeling that the documentation for such a project
> would look more like a simple placeholder or something easily outdated
> than anything. Furthermore, since there isn't a clear main window of
> the application, it would be unintuitive to get there. We're convinced
> nobody would ever end up there.
>
> Aleix

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Cervisia?

[Jeremy Whiting]

Well, it was released as part of Applications 15.08.0 (and will be in
the rest of the .x releases) I'm fine either way, but it seems like
continuing to release something that hasn't been looked at in quite
some time. I think to continue to release it we would need to have:

1) A port to Qt5/KF5 which could be difficult with Qt3Support stuff in
it, tricky but doable.
2) A maintainer.

Anyone want to try taking on one or both of those?

thanks,
Jeremy


On Mon, Sep 14, 2015 at 1:48 PM, André Wöbbeking <woebbek...@kde.org> wrote:
> Hi,
>
> On Sunday 13 September 2015 16:31:55 Jeremy Whiting wrote:
>> Hey all,
>>
>> I think I may have found another cruft to move to unmaintained.
>> Cervisia is a gui for cvs. The last non trivial change to it was
>> around 2011 everything since has been preparing it for git migration,
>> bumping version, scripty, fix docbook issues, etc. It hasn't been
>> ported to Qt5/KF5 obviously. Should we kill it? If anyone objects let
>> me know this week sometime, otherwise it will join unmaintained.
>
> I'm, well was a developer of Cervisia and when Christian stepped down as
> maintainer I tried to take care of bugs. But for some years now I've less time
> due to real life.
>
> Of course I thought about porting to Qt5 but Cervisia still uses Qt3 classes
> (well, even Qt2 :-) and nowadays cvs isn't used that much any more. So it's
> probably time to let it rest in 4.14 or to move it to unmaintained.
>
>
> Cheers,
> André

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

As shown here: http://developer.kde.org/~cfeck/portingstatus.html
(under Extragear base) It is missing a manual. Needs a Feature_summary
added to CMakeLists.txt and some .desktop files should be renamed to
org.kde.foo.desktop.

I just tried it out and it seems to work here, though I'm not seeing
sms notifications in the desktop like I expected (I am able to control
cantata from my phone though, which is handy). Yes I installed the
beta on the play store.

BR,
Jeremy


On Sat, Sep 12, 2015 at 6:29 AM, Albert Vaca  wrote:
>> I moved the translations for both repositories. Please update the
>> translations
>> branches for kdeconnect-android so that trunk_kf5 is master and trunk is
>> none;
>> yes, it's android and it does not matter, but it's easier for us.
>
>
> Done.
>
>>
>> Translation branches for kdeconnect-kde are fine (translations moved few
>> months ago). In addition to master, we track also the 'kde4' branch. Do
>> you
>> plan to release additional versions from there, or can we drop that
>> branch?
>
>
> Removed kde4.
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

As shown here: http://developer.kde.org/~cfeck/portingstatus.html
(under Extragear base) It is missing a manual. Needs a Feature_summary
added to CMakeLists.txt and some .desktop files should be renamed to
org.kde.foo.desktop.

I just tried it out and it seems to work here, though I'm not seeing
sms notifications in the desktop like I expected (I am able to control
cantata from my phone though, which is handy). Yes I installed the
beta on the play store.

BR,
Jeremy


On Sat, Sep 12, 2015 at 6:29 AM, Albert Vaca  wrote:
>> I moved the translations for both repositories. Please update the
>> translations
>> branches for kdeconnect-android so that trunk_kf5 is master and trunk is
>> none;
>> yes, it's android and it does not matter, but it's easier for us.
>
>
> Done.
>
>>
>> Translation branches for kdeconnect-kde are fine (translations moved few
>> months ago). In addition to master, we track also the 'kde4' branch. Do
>> you
>> plan to release additional versions from there, or can we drop that
>> branch?
>
>
> Removed kde4.
>

Cervisia?

[Jeremy Whiting]

Hey all,

I think I may have found another cruft to move to unmaintained.
Cervisia is a gui for cvs. The last non trivial change to it was
around 2011 everything since has been preparing it for git migration,
bumping version, scripty, fix docbook issues, etc. It hasn't been
ported to Qt5/KF5 obviously. Should we kill it? If anyone objects let
me know this week sometime, otherwise it will join unmaintained.

thanks,
Jeremy

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

+1 here too.

On Thu, Sep 10, 2015 at 3:39 AM, Albert Vaca  wrote:
> +kde-core-devel
>
> Hi,
>
> With the latest changes we are making to KDE Connect as part of the sprint
> in Randa, I think that the project is becoming mature enough to be moved out
> of playground. Not only that, but Kubuntu and other distros are already
> installing KDE Connect by default, regardless of it being in playground.
>
> I think that extragear/network is the best place for KDE Connect to be in,
> as we don't want to be tied to external release schedules for now.
>
> Any thoughts?
>
> Albert
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

Re: Moving KDE Connect out of playground

[Jeremy Whiting]

+1 here too.

On Thu, Sep 10, 2015 at 3:39 AM, Albert Vaca  wrote:
> +kde-core-devel
>
> Hi,
>
> With the latest changes we are making to KDE Connect as part of the sprint
> in Randa, I think that the project is becoming mature enough to be moved out
> of playground. Not only that, but Kubuntu and other distros are already
> installing KDE Connect by default, regardless of it being in playground.
>
> I think that extragear/network is the best place for KDE Connect to be in,
> as we don't want to be tied to external release schedules for now.
>
> Any thoughts?
>
> Albert
>
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
>>> <<
>

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

Re: Adding further modules to api.kde.org

[Jeremy Whiting]

Martin,

I took a look at this as part of the gardening documentation websites,
but I didn't get very far. The code that runs this and ebn is in
kde:websites/quality-kde-org and is pretty outdated unfortunately.
Actually now that Allen Winter is back maybe he could add it (Added
him to cc)? What I tried here during gardening which I couldn't get to
work locally was:

1. Install it (I had some trouble with the perl based installer
putting files in different places than expected, maybe perl itself
changed over the years?)
2. Once I manually copied some files to places where they were
expected I couldn't figure out how to manually run the doc generator,
the --help documentation mentioned what arguments to use, but it
wasn't obvious what I should put for my Qt documentation paths and
such somehow, so I didn't try anything further.

It would be awesome to have what used to be in KDE SC on api.kde.org
again. We have many libraries that aren't frameworks that are Qt5/KF5
based which would be good to show on there imo.

BR,
Jeremy

On Thu, Sep 10, 2015 at 2:57 AM, Martin Graesslin  wrote:
> Hi all,
>
> back in KDE4 days the workspace libraries were listed on api.kde.org [1]. But
> for the current version we don't have any API docs available. The section
> "Other KDE Software" [2] lists KDE Support, KDE Extragear and Playground but
> apparently nothing from what used to be KDE SC.
>
> Does anybody know how I can get our KDE Workspaces listed there again? I'm in
> particular interested in getting KWayland API documentation published.
>
> If nobody knows: does anyone know who needs to be poked.
>
> Cheers
> Martin
>
> [1] http://api.kde.org/4.x-api/kde-workspace-apidocs/
> [2] http://api.kde.org/other.php

Re: Adding further modules to api.kde.org

[Jeremy Whiting]

Well, it's not even just about workspace, we had in kde4 times kdeedu,
kdegames, etc. etc. all on api.kde.org. Not all of it was api per se
(I don't know anyone that would want to read the apidocs for kanagram
for example, except to know how it's internals work or used to work
when hacking on it). Currently we only show frameworks and other. This
misses a lot of useful documentation, nothing is there about
libkomparediff2, libkeduvocdocument, libkdegames, etc. since those
aren't generated anymore for some reason.

A good idea that Ben suggested when the gardening project started was
having the apidocs generate on commit, rather than regenerating
everything every night at a specified time. A lot of the sources don't
actually change very often, so rebuilding part of the apidocs when the
code or it's doxygen comments change would make a lot of sense.

BR,
Jeremy

On Thu, Sep 10, 2015 at 11:05 AM, Adriaan de Groot <gr...@kde.org> wrote:
> On Thursday 10 September 2015 06:07:40 Jeremy Whiting wrote:
>> It would be awesome to have what used to be in KDE SC on api.kde.org
>> again. We have many libraries that aren't frameworks that are Qt5/KF5
>> based which would be good to show on there imo.
>
> Perhaps half of this is figuring out what actually constitutes the "Workspace
> API" that would be interesting here and how to subsequently pull information
> out of the metadata-services that we have (src-build? projects.kde.org? I
> don't know, I haven't followed very closely what lives where now).
>
>
>
> [ade] (who is now reminded that the original ebn domain is expiring and needs
> renewal, yeah)

Re: Adding further modules to api.kde.org

[Jeremy Whiting]

Allen,

Those are both KDE4 versions of workspace stuff. I don't see any place
where kf5 versions are.

BR,
Jeremy

On Thu, Sep 10, 2015 at 1:50 PM, Allen Winter  wrote:
> On Thursday, September 10, 2015 10:57:10 AM Martin Graesslin wrote:
>> Hi all,
>>
>> back in KDE4 days the workspace libraries were listed on api.kde.org [1]. But
>> for the current version we don't have any API docs available. The section
>> "Other KDE Software" [2] lists KDE Support, KDE Extragear and Playground but
>> apparently nothing from what used to be KDE SC.
>>
>> Does anybody know how I can get our KDE Workspaces listed there again? I'm in
>> particular interested in getting KWayland API documentation published.
>>
>> If nobody knows: does anyone know who needs to be poked.
>>
>
> http://api.kde.org/4.x-api/workspace-apidocs/ exists
> The KDE SC stuff is shown under "KDE4 Versions" 
> http://api.kde.org/history4.php
>
> I do notice that under the various KDE 4.foo tables we don't have a workspace 
> entry
> we have kde-workspace, but not workspace.  seems like kde-workspace and 
> workspace are similar.
>
> I'm not sure there's anything to fix.
>
> -Allen
>
>