headers
Martin Gräßlin | 1 Oct 2011 08:21
Picon
Favicon

Fwd: Re: "gamer" mouse button shortcuts (LONG)

forgot to add kcd
----------  Forwarded Message  ----------

Subject: Re: "gamer" mouse button shortcuts (LONG)
Date: Saturday 01 October 2011, 08:19:47
From: Martin Gräßlin <mgraesslin <at> kde.org>
To: Kwin, NET API, kwin styles API, kwin modules API <kwin <at> kde.org>

On Friday 30 September 2011 15:14:10 Rick Stockton wrote:
> I've been inspired by the 'shortcut doc' Thread on kwin ML. This 
> concerns mouse devices with "extra" buttons driving our desktop, and 
> creating mouse-based shortcuts.
> 
<snip long part>
> - - - - - -
> So here's the questions:
> 
> FIRST:  If I (and maybe some helpers too) can crunch it fast enough for 
> 4.8, would you all like to have it in there?
Redesigning the effects KCM would be great but that is nothing for the 4.8 timeframe. It is nothing that I
would do 
without a proper useability study and I am very much against copying the design of CCSM. I consider it us
magnitiudes 
worse than our current KCM (which sucks but that's a different story). The CCSM gives focus on the large 
functionality and complexity of the system. This has to be hidden from the user. AFAIK not even Ubuntu
(being the last 
relevant distro defaulting to Compiz) is shipping the CCSM by default.

Especially something like mouse shortcuts have to be configurable in the same way as all other shortcuts.
It would be
(Continue reading)

Permalink | Reply | 2 comments |
headers
Martin Gräßlin | 1 Oct 2011 08:27
Picon
Favicon

Re: Re: The case for a kdelibs 4.8

On Saturday 01 October 2011 00:12:05 Arne Babenhauserheide wrote:
> Am Freitag, 30. September 2011, 10:07:27 schrieb Aaron J. Seigo:
> >  will say "Platform 4.7, Plasma 
> > Workspaces 4.8 and application updates" (or something along those lines).
> > that  was not just a marketing ploy, but an attempt to align our public
> > communication with the realities that already existed in KDE development.
> 
> I hope I am not the first to note that this sounds really horrible. 
> 
> Take this message: 
> 
> 	KDE releases 4.8: Platform and Workspaces got some spectacular changes, 
> while applications received much polish.
> 
> In a blog, this becomes
> 
> 	YAY! KDE releases 4.8!
> 
> Take your example. It becomes: 
> 
> 	Plasma 4.8 released!
> 
> Well, where is KDE in that? Suddenly the community it is all about becomes a 
> sidenote. 
> And a newspaper will likely only see “hm, some stuff our readers won’t 
> understand” instead of “new version of the tools from KDE!”
> 
> There is a reason why Apple releases MacOSX 10.8 and not “Xcode 4.1, Apple 
> Mach 1.3, Quartz 4.7, …”
One of the main reasons for the rebranding was to realize that "KDE" is not one product, but a community that
(Continue reading)

Permalink | Reply | 3 comments |
headers
todd rme | 1 Oct 2011 09:59
Picon

Re: Re: "gamer" mouse button shortcuts (LONG)

On Sat, Oct 1, 2011 at 8:21 AM, Martin Gräßlin <mgraesslin <at> kde.org> wrote:
> forgot to add kcd
> ----------  Forwarded Message  ----------
>
> Subject: Re: "gamer" mouse button shortcuts (LONG)
> Date: Saturday 01 October 2011, 08:19:47
> From: Martin Gräßlin <mgraesslin <at> kde.org>
> To: Kwin, NET API, kwin styles API, kwin modules API <kwin <at> kde.org>
>
> On Friday 30 September 2011 15:14:10 Rick Stockton wrote:
>> I've been inspired by the 'shortcut doc' Thread on kwin ML. This
>> concerns mouse devices with "extra" buttons driving our desktop, and
>> creating mouse-based shortcuts.
>>
> <snip long part>
>> - - - - - -
>> So here's the questions:
>>
>> FIRST:  If I (and maybe some helpers too) can crunch it fast enough for
>> 4.8, would you all like to have it in there?
> Redesigning the effects KCM would be great but that is nothing for the 4.8 timeframe. It is nothing that I
would do
> without a proper useability study and I am very much against copying the design of CCSM. I consider it us magnitiudes
> worse than our current KCM (which sucks but that's a different story). The CCSM gives focus on the large
> functionality and complexity of the system. This has to be hidden from the user. AFAIK not even Ubuntu
(being the last
> relevant distro defaulting to Compiz) is shipping the CCSM by default.
>
> Especially something like mouse shortcuts have to be configurable in the same way as all other shortcuts.
It would be
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin Kofler | 1 Oct 2011 12:11
Picon

Re: The case for a kdelibs 4.8

Aaron J. Seigo wrote:
> the features that got into the 4.7 branch to date have been things that
> were already worked on before the Frameworks decision was made. it's was
> an odd cas were features had been worked on while 4.7 was frozen with the
> expectation of a 4.8 ... and that left us with the choice of having a 4.8
> release which we didn't want for those few features, leaving those
> features out and screwing up the planning of the applications depending on
> those changes or fudging a little bit.

Not all those features are merged in yet, see e.g. my Plasma PackageKit GSoC 
work.

> note that some of the more actively changing and developed code in kdelibs
> have moved to separate git repositories already to make this issue moot
> for them (kactivities, nepomuk)

That is also a nightmare to packagers. Especially kactivities is a big 
problem because kde-workspace 4.7 (not 4.8!) is now reported to rely on a 
new kactivities which is not in kdelibs 4.7. That makes no sense whatsoever.

        Kevin Kofler
Permalink | Reply | 0 comments |
headers
Kevin Kofler | 1 Oct 2011 12:17
Picon

Re: The case for a kdelibs 4.8

Martin Gräßlin wrote:
> Have you actually tried to get the fedora patches into the 3.5 branch? I
> cannot remember any discussion about it on kcd...
> 
> Even if upstream would say no to the feautures what is wrong with doing a
> distro-3.5 branch so that at least all distros can have the same patches?

Distributions work from tarballs and patches, not checkouts, so a branch 
won't help us all that much if no releases are being done from it. Sure, we 
can take snapshots, but we can also just patch the last release.

And FWIW, these days, in Fedora, apart from the patches we've already had 
for years (such as that Hunspell patch), we're only applying compilation and 
security fixes to kdelibs3. I doubt we'll need anything else at this point. 
The KDE 3 libs are now very old. The situation is different for kdelibs 4.x 
though.

        Kevin Kofler
Permalink | Reply | 0 comments |
headers
Kevin Kofler | 1 Oct 2011 12:31
Picon

Re: Re: The case for a kdelibs 4.8

Martin Gräßlin wrote:
> One of the main reasons for the rebranding was to realize that "KDE" is
> not one product, but a community that produces multiple products among
> them a desktop environment (Plasma). What you just try to tell us is that
> the complete rebranding is nonsense and we should go back to talking just
> about KDE for everything bringing the users back to assuming they need
> Plasma in order to use KMail.

That's what some of us have been trying to tell you for months…

        Kevin Kofler
Permalink | Reply | 0 comments |
headers
Kevin Kofler | 1 Oct 2011 12:58
Picon

Re: The case for a kdelibs 4.8

Aaron J. Seigo wrote:
> so some features will indeed have to wait .. and that's not a horrible
> thing because it means that frameworks will get more developer attention
> and the attention it is getting already will not be slowed even further by
> having to deal with bringing over features from 4.7.x into the re-arranged
> libraries in frameworks.

So you're arguing that by doing this, you FORCE developers to work on 5.0? 
Well, I'm sorry, but you cannot really force volunteer developers to do 
anything. I don't believe that actively preventing us from working on the 
branch we want to work on is going to solve any problem.

> the result will be that the time between now and 5.0 libs being available
> will be shortened, which is exactly what we, as application developers,
> need.

I also strongly doubt that yet another binary-incompatible break is what 
application developers really want or need. Some applications are still not 
ported to the KDE Platform 4.

(And I know that Qt is also breaking the ABI. That's something I also can't 
agree with, especially considering that Qt 4 was advertised as "the big ABI 
break which will make new ABI breaks unnecessary for a very long time" and 
we've been continuously told that "there are no plans whatsoever for a Qt 5 
any time soon", almost up to the day before the Qt 5 announcement. But I 
realize that this is out of KDE's control.)

> there is apparently a fundamental misunderstanding here: KDE Platform 4.7
> is being maintained. but "only" maintained. if such a spell checker thing
> happened right now, we could enable that in the 4.7 branch. many of us are
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin Kofler | 1 Oct 2011 13:27
Picon

Re: The case for a kdelibs 4.8

PS:

Aaron J. Seigo wrote:
> the choice that packagers have is to actually work with us instead of
> against us.

We would very much love to work with you. In fact, this is why I submitted 
my patches to KDE ReviewBoard before even getting them into Rawhide. I 
really WANT these to be upstream. Fedora doesn't like carrying downstream 
patches as a general principle.

However, working with you is only possible if you are also interested in 
working with us, which implies listening to our needs, concerns and wishes. 
By closing down the branch where our current development is necessarily 
focused on since that's what we will be shipping in the near future, you're 
already starting down the wrong road.

For those Plasma PackageKit features, sure, they're not strictly required, 
which is why we got away without them until now. But to our users, they mean 
that installing a widget through "download new widgets…" will actually 
install the required dependencies, so the widget they downloaded will 
actually WORK. What, to us developers, is a feature, actually fixes a bug 
from a user's perspective. We, the distributions, interact directly with 
users, and so are receptive to their needs, concerns and wishes, and tend to 
base ours on them.

And finally, I strongly doubt that my features are the only post-4.7 kdelibs 
features running into the freeze. (In fact, what's now going on with 
kactivities and nepomuk proves quite the opposite.)
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kevin Kofler | 1 Oct 2011 13:45
Picon

Re: The case for a kdelibs 4.8

PPS:

I wrote:
> However, working with you is only possible if you are also interested in
> working with us, which implies listening to our needs, concerns and
> wishes. By closing down the branch where our current development is
> necessarily focused on since that's what we will be shipping in the near
> future, you're already starting down the wrong road.

For a prime example of what happens if you close down the version 
distributions are actually shipping in favor of long-term development, just 
look at GRUB 1. Fedora's GRUB 0.97 package is now at patch level 75! And it 
has its own git repository, i.e. essentially a fork (grub-fedora on 
git.kernel.org, it's now down because all of git.kernel.org is currently 
down).

GRUB 2 is now finally becoming production-ready, and Fedora will be 
switching to it in Fedora 16, but it was nowhere near that state when 
upstream discontinued GRUB 1. GRUB 0.97 was released on May 8, 2005 (and 
IIRC that was only a bugfix release and they stopped accepting new features 
even earlier). Distributions have been forced to ship patched versions for 
over 6 years. (GRUB 0.97 as released doesn't support many needed features, 
e.g. ext4.) As a result, it has become a morass of all-different forked 
versions. You can't tell a priori what any given "GRUB 0.97" package 
actually supports.

Sure, focusing on the long term to some extent is needed, but we 
distributors need something we can ship NOW, not months or years from now.

        Kevin Kofler
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thiago Macieira | 1 Oct 2011 14:02
Picon
Favicon

Re: The case for a kdelibs 4.8

On Saturday, 1 de October de 2011 12:58:01 Kevin Kofler wrote:
> (And I know that Qt is also breaking the ABI. That's something I also can't 
> agree with, especially considering that Qt 4 was advertised as "the big ABI
> break which will make new ABI breaks unnecessary for a very long time" and
> we've been continuously told that "there are no plans whatsoever for a Qt 5
> any time soon", almost up to the day before the Qt 5 announcement. But I
> realize that this is out of KDE's control.)

Between the 4.0 and 5.0 release, it will have been 7 years. I think it's long 
enough.

KDE could take Qt 4.8, fork it and continue developing it. Any show of hands?

As for the announcing of the plans, there were no plans to do Qt 5 until there 
were plans. Once there were plans, they were announced.

--

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
Permalink | Reply | 0 comments |

Gmane