Re: git and artworks issues
On Tuesday 20 December 2011, Davide Bettio wrote: As every year some artworks are changed according to the new default desktop background. This year I noticed some problems: 1) kdm and ksplash default theme is part of kde-workspace. I need to update both, but if I do that I will have to commit about 20/30 MiB of PNGs making git clones bigger. Thats life, you need to push it there. We can decide to move it to other places after 4.8.0, but now it is a bit too late. 2) I need to update kdeui/about backgrounds, but If I do that I will change backgrounds also for the KDE 4.7 branch. There are two possibilities: a) create a kdelibs KDE/4.8 branch for this purpose. (plus the patch to make kdelibs 4.7 actually look like KDE 4.8, which I currently apply to the tarballs only (in kde-common/release/make-kdelibs-4.8.diff) b) add a tarball of artwork that I need to unpack in kdelibs prior to creating the actual release tarball to kde-common/release/* as well) For me, it would make most sense to create a KDE 4.8 branch in kdelibs, but I would like to have more input before I create the branch. Any opinions on this matter? Thanks, Dirk
Re: git and artworks issues
On Tuesday 20 December 2011, Davide Bettio wrote: On Tuesday 20 December 2011, Dirk Mueller wrote: Perfectly fine with that if you can do it now and not break anything and make it all work smoothly. As I think that is a too short notice, lets do it for 5.0. I do it now. could you please do it in /branches/KDE/4.8/kde-base-artwork instead and let me know once it is in? Thanks, Dirk
Re: KDE/4.8 branch created
Am 20.12.2011 22:18, schrieb Dirk Mueller: Hi, As a preparation of KDE 4.8 RC1 I've created a KDE/4.8 branch for all released modules except for kdelibs, where I'm waiting for feedback if creating a 4.8 branch makes sense for just one patch (see other mail today). I have at least one patch pending that has been applied to 4.7 but I couldn't apply it to master because it was restricted. Please remember that from now on, any change that should be part of KDE 4.8.0 must be pushed to the KDE/4.8 branch. (for those modules that are in SVN, a /branches/KDE/4.8/* tree has been created). The only exception that exists (as usual) is kde-l10n ,which is still taken from /trunk/l10n-kde4 until 4.8.0 release. so nothing changes for translators so far. Thanks, Dirk regards, Patrick
Re: git and artworks issues
El Dimarts, 20 de desembre de 2011, a les 20:18:17, Dirk Mueller va escriure: On Tuesday 20 December 2011, Davide Bettio wrote: As every year some artworks are changed according to the new default desktop background. This year I noticed some problems: 1) kdm and ksplash default theme is part of kde-workspace. I need to update both, but if I do that I will have to commit about 20/30 MiB of PNGs making git clones bigger. Thats life, you need to push it there. We can decide to move it to other places after 4.8.0, but now it is a bit too late. 2) I need to update kdeui/about backgrounds, but If I do that I will change backgrounds also for the KDE 4.7 branch. There are two possibilities: a) create a kdelibs KDE/4.8 branch for this purpose. (plus the patch to make kdelibs 4.7 actually look like KDE 4.8, which I currently apply to the tarballs only (in kde-common/release/make-kdelibs-4.8.diff) Yes please, create a KDE/4.8 branch too for kdelibs. Albert b) add a tarball of artwork that I need to unpack in kdelibs prior to creating the actual release tarball to kde-common/release/* as well) For me, it would make most sense to create a KDE 4.8 branch in kdelibs, but I would like to have more input before I create the branch. Any opinions on this matter? Thanks, Dirk ___ release-team mailing list release-t...@kde.org https://mail.kde.org/mailman/listinfo/release-team
More devices into the Shortcut system...
It is time for us to Fish, or Cut Byte on two alternative ways to introduce Mouse-Oriented Shortcuts into Qt5 and KDE-Next: Todd RME has been suggesting a new design- oriented around DBUS. Unfortunately, I don't know how to do that coding. Todd, if your design gets a more favorable review from THIS group, within the next few days, I'll try to assist you in your work (as best as I can; I'm definitely not the brightest person here.) As an alternative, I'm suggesting the idea of enhancing one or two of the existing classes: I'd prefer to enhance the current QShortCutEvent and QShortCut scheme, so that they can include Mouse Button events within a QKeySequence. (This will including the possibility of _only_ one or more Mouse Buttons, with no keyboard event at all.) If that proves difficult, I could create new Classes to do this-- but I think I can use the 'hasExtendedInfo' trick which one of the smart Qt guys has used to handle a variety of Signatures in the QtMouseEvent() code. I can work with *this* stuff on my own. Please give opinions soon, as we have only 3-5 weeks before the Qt5 API goes into soft freeze. After we have Mouse Buttons done, the same design could be extended to handle other input devices (joystick, multitouch, and so on.)
