[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: [Announce] KPDF2-0.3.0 released
From:       Krzysztof Lichota <krzysiek () lichota ! net>
Date:       2007-02-06 13:26:25
Message-ID: 45C88201.70602 () lichota ! net
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Aaron J. Seigo napisał(a):
>> It is creating "cool factor" which is really important for young people.
> 
> and what about the majority of people who need something more than this? it's 
> all about balance and managing multiple sets of needs, something i see 
> completely missing from most of the discussion in this thread.

You can choose not to use compositing manager. But there are some people
that do want to use it (not me, BTW).

>>>> I have not used accessibility.
>>> i was kde's first envoy to the fsg accessibility group some 4 years ago.
>>> thankfully others came along to help out and take over who are more
>>> interested and vested in the topic than i am. but it has given me a
>>> decent vantage point  =)
>> Accessibility is most important for me as a way to automatically test
>> user interfaces. I think we lack this KDE.
> 
> agreed. and so we're working hard on bringing it into kde. it's feasible with 
> kde4 and hard as hell with kde3.

I agree accessibility is for KDE4.

>>> yes, it does. (god, why am *i* of all people on *this* side of the
>>> conversation? ;) it also needs to happen at the right time and in the
>>> right ways, as i'm sure you'll agree.
>> Yes. The whole point of my e-mail was to put more effort into KDE3
>> development, because KDE4 is long way to go. Unfortunately I see a lot
> 
> at some point we need to get kde4 out the door. if we don't put effort into 
> kde4 that'll never happen. your examples include things that will be key 
> components on a kde4 desktop (and so need to be worked on) or are completely 
> at a dead end with qt3 (e.g. koffice's text layouting)

If things are impossible (or very hard) to do in KDE3, then I
understand. But there are things which can be improved in KDE3.

>> And it means that until everybody is using KDE4, nobody will see these
>> improvements. So nobody will use them for another year.
> 
> and the problem is?

Recent example: some guy announced rewritten KBabel (of course in
trunk), which should improve a lot of things (KBabel in KDE3 was
degenerating for a lot of time now). For me it is completely useless as
I don't use KDE4 and I guess most of translators do not use KDE4. So a
very welcome improvement is not seen for another year. It would be much
better if the path would be: KBabel in KDE3 -> improvements -> porting
to KDE4. Currently it is: KDE3 broken -> will be fixed in KDE4.

>>> happen since the corba and bonobo vs dcop and kparts days. it's never
>>> been true and it isn't true.
>> I am not saying they are better :)
>> I am saying they keep delivering new stuff over the period when KDE
>> development seems "stalled".
> 
> the "road to kde4" series and the commit digest are nice data points. however, 
> you seem to be saying there is, in your opinion, a public perception problem. 
> if so, please take this thread to kde-promo and help fix it by doing what the 
> people writing articles and talking to the public about kde4 are doing.

I am not talking about promotion of KDE4. We have been hearing about
great KDE4 features for a long time. It does not help situation of
people stuck with KDE3, though. Those people need some improvements in
their environment, not more words.

>>> beagle: swahili for overrated. even gnome is moving to tracker, which is
>>> much more like strigi than anything else. and the vandeoever, the strigi
>>> architect, is the guy who is leading standardization in this area on
>>> fd.o;
>> I agree on Beagle. But it is in use and creates "look, it indexes
>> webpages I visited!" cool factor. Strigi is not part of KDE3, so again
>> -> KDE4.
> 
> strigi works with kde3. you're right that we won't have widespread integration 
> of search and semantic networks until sometime in the kde4 series, but that 
> is exactly NO different than doing it in kde3. or are you operating under the 
> flawed assumption that adding it to kde3 would be less work?

Widespread integration and semantic desktop is not feasible for KDE3.
Adding it to KDE as official desktop search tool with applet and maybe
some tweaking of "open file" dialog _is_ possible and could have great
effect with little effort.

I think there should be one more "big functionality release" for KDE3.
Name it KDE 3.5.8 or KDE 3.6, it doesn't really matter. But bring
together all the improvements done or in progress so far (kdepim_3.5.5+
branch, kwin_composite, strigi, suse_kickoff, opensync, I guess you know
more worthwhile features), tackle most important bugs and reasonable
wishes, and then you can let users wait for great step forward which
KDE4 will hopefully be.

BTW. I think by requiring improvements to KDE 3.5 branch to be first
tested in trunk you are losing some manpower. I, for example, would be
willing to work on some features for KDE 3, but burden of working on
develoment branch (which will not be used by people for a long time), is
not appealing to me. I guess I am not the only one.

>> If this bug could not be solved in current KDE3 architecture, then I
>> think there would be something seriously wrong with KDE3 architecture.
>> And I don't think this is the case.
> 
> in the case of PIM storage and retrieval in KDE3, you're wrong. there are lots 
> of great things in KDE3, this isn't one of them. it doesn't suck, but it's 
> not great either.

Has anyone tried to fix it? Can you point me to the discussion or tell
me which part of code is the problem? I would like to take a look at it.

	Krzysztof Lichota



["signature.asc" (application/pgp-signature)]

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


[prev in list] [next in list] [prev in thread] [next in thread]