KDE Traffic #37 For 21 May 2002

Welcome to KC KDE! After Aaron J. Seigo has retired as editor, the Kernel Cousin KDE Team returns with some new members and two editors in a weekly change: Zack Rusin and myself, Juergen Appel. With KDE 3.0.1 to be released real soon, development focuses again on the upcoming 3.1 release including a Kopete that is taking more and more shape, an enhanced Kicker and besides an upgraded KBugBuster.

KMathCenter is a math science application wich intents to go into the kde-edu package set.

The current features of KMathCenter are:

symbolic derivations
symbolic expression simplifications
string based expression calculation.
analytic function plotter

The current features goals are as follows:

symbolic expression integration
symbolic expression expanding
everything else you need to compute a complete curve discussion (I unfortunately can't say these things in english)
scripting system for advanced mathematical algorithms

KMathCenter has also some requirements:

KDE 3 (of course :o)
OpenGL (at least MesaGL, software driven - www.mesa3d.org)
libmath++ (is bundled into the package)
ISO/ANSI C++ compliant compiler (that's mostly gcc3, for gcc2 exists a source level fallback, so it'll work there too)

[..]

Screenshots of KMathCenter made while coding on it are available at:

http://www.surakware.net/projects/kmathcenter/shots.xml

Download of that initial package for testing is available at:
http://www.surakware.net/downloads/kmathcenter-testing.tar.gz

You surely have noticed that KMathCenter is using libmath++, it's developement state till now may be reviewn at:

http://cvs.surakware.net/viewcvs.cgi/libmath++/

[..]

BTW: Qt's qgl.h also includes GL/glu.h even if it isn't ever needed. KMathCenter will never need that header but you need it because Qt thinks that it's needed. (That's not good!, since we noticed that average Mandrake users doesn't have either OpenGL nor its include files, such as the important glu.h for Qt! It's not my fault ;)

Anne-Marie Mahfouf replied concerning Christian's wish to include KMathCenter in the upcoming KDE 3.1 release, saying, "It seems difficult to include KMathCenter in HEAD for 3.1 due to the OpenGl problem and due to the fact that we already have KmPlot."

Discussion continued about merging KMathCenter with KMathTool, kmplot and other projects, but it was concluded that these applications can exist side-by-side.

Ladislav Strojil wrote in a suggestion for the AutoAway plugin of multi-protocol instant message client Kopete, saying, "The problem (at least for me) is that it restores status to available, no matter what it was before setting "away" status."

Daniel Stone confirmed this was due to differences between the protocols, saying, "This is indeed the only way to handle this. Since each plugin stores its own status - int, QString, whatever, and in an incompatible way, and sets its presences differently, this would have to be implemented on a per-plugin basis"

The discussion soon focused on using the KopeteStatus class by Ryan Cumming, encapsulating the away modes from different protocol plugins. While it was agreed upon that this would be the ideal solution, there was no response to the list that such a class was already existing. Lada finished the thread, indicating a will to write the necessary code, saying, "OK, I am willing to do that, I'll ask Ryan about it and if there is nothing I will start from scratch. I may need your assistence however, I am new to kopete development (well, to be precise I started looking at the code yesterday)."

Kopete is one of the newer KDE applications and as such the developers are still frequently discussing design issues, trying to create a unified and consistent interface while handling various protocols and their differences. A special CVS branch exists for the new KMM message window.

Andres Krapf wrote a lengthy e-mail about some problems with the current KMM design and suggested:

the best way i see to keep using the nice KMM functionality while allowing full customisation is either to allow subclassing of KMMs (which i think is a good thing).

if we go that way, there's the probem of the factory. we could use a factory method provided by the plugin, but then we'd have to dynamic cast like here:

(inside, say, AIMProtocol class)


/* this calls the KMMF::create which in turns calls some method provided by
the plugin which creates a AIM specific AIMProtocol*)
*/
KMM* kmm = sessionFactory()->create(blah);

/* we have to dynamic cast */
AIMProtocol* aimkmm = dynamic_cast<AIMProtocol*> kmm;

a better solution might be to use a factory template. like this:


template <class KMMT> class KMMFactory {
        KMMT create (blah) {
                if exists blah inside KMM list
                        return KMM list item;
                else
                        return new KMMT(blah);
        }
}

so that we reuse the code, but each protocol gets its own factory returning its own KMM (AIMKMM, ICQKMM .....) and we don't have to dynamic_cast.

we could still provide the generic KMM for plugins which don't require any customization (or aren't there yet).

comments ?

Yes: what the heck do you need this for? It is extremely complex, messy and sounds seriously overengineered to me. Is there a *need* for this or are you thinking about things like 'well, we _might_ want to do blah in the very distant future and then we need this' ? If so I'd rather leave things as they are now, fixing what needs fixing *now*. I want all plugins to use KMM ASAP and stabilize to get Kopete 0.4 out of the door based on it. After that we're a long way to shared code and then it might be a nice time to talk about the API again. We're not heading for BC yet, so please take small incremental steps. After all, open source is 'release early, release often', and this way the gap between Kopete releases will be *way* too big. If you need this to stabilize or finalize the current code then please explain and we might incorporate it. In all other cases: please wait at least until KMM is back into HEAD and a Kopete 0.4 is out. After that, start the discussion again.

While the pros and cons of the different approaches were discussed even further in the following e-mails, it was agreed upon that such a redesign and discussion about it should indeed be postponed. It should be interesting to see how Kopete struggles with growing into a mature application. There still seems a lot to be done, but the volume of traffic on the mailinglist and dedication from its developers promise a lot for the future.

For some time, the KDE Usability Project has been discussing various usability issues in KDE and working on improvements in many of the small-but-useful programs such as KSnapshot. More confident and experienced, the team decided it was time to concentrate on other areas of KDE. The Kicker configuration dialog and KControl module was chosen as the next candidate. After a lengthy period of discussion with input from a wide range of people on the kde-usability mailing list, and coding the required changes, Aaron J. Seigo posted a message to the mailing list to represent the culmination of this phase of the KDE Usability project:

i've committed the changes to the kicker kcm and kicker itself. documentation, proofing the spelling and contents of the tooltips and WhatsThis help, and getting rid of the extensions panel in the kcm is left to do (along with processing any bug reports / complaints / questions that this commit incurs)

thank-you to everyone who provided criticisms, feedback, improvements, opinions, etc etc .... without your ideas and input it wouldn't be *nearly* as good as it turned out.

this is probably the most visible change yet to come out of the usability project and i think that it has gone very well so far...

The KDE Bug Tracking system is an excellent resource for both users and developers. It serves as a mediation point for defect reports and wishlist items that can be driven by the web interface, email or the KBugBuster application. The system does require that people use it to be effective, however. David Faure forwarded on an email from Jörg Mayer who said:

Having reported/opened a few bugs and having looked at some bug reports before opening I've come upon two things that I'd like to comment on (aka criticize :-)

When you close a bug, please indicate which release version is likely to contain the fix (I just wanted to report a bug and found that it was fixed and closed on March 8th, but I'm still seeing the bug in kde 3.0, so does opening a bug report make sense?)
When you close a bug as a duplicate, please indicate of which bug this is a duplicate. I've had one of my bugs closed as a duplicate but even after searching for that bug, I haven't found it. I've also seen a few more bugs that were closed as duplicates without me being able to find the original one.

Marc Mutz agreed with the first point but took exception to the Jörg's second assertion saying, "IMO it's the reporter's job to find the dup or simply believe us. I had someone mailing me that he "searched" the wishlist items of KMail and didn't find a dup of item I had closed as being duplicate. _Two_ days later, he wrote back that he had indeed found one. I _know_ duplicates when I see them, the more so as I have been going to all the wishlist items recently, cleaning up. Yet I cannot afford to search the exact number everytime I close a wish/bug. It'd regularly take 10+ minutes to find that I can't find it myself. But it _is_ there."

It was pointed out that KBugBuster has an offline mode for those who don't have flat-rate Internet access. Some suggested that KBugBuster would be more useful with a full-text searching mechanism. KBugBuster is a very good tool and a step in the right direction, but evidently more needs to be done before it is the bug report handler's dream system.

Fredrik Hoeglund recently added the Keramik KWin decoration to CVS, to complement the highly original Keramik widget style which has been in the development version for a while, although unfortunately not included in KDE 3.0.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	30 Apr 2002	(24 posts)	More Mathematics in KDE 3.2?
2.	4 May 2002	(8 posts)	Auto-away in Kopete
3.	8 May 2002 - 13 May 2002	(14 posts)	Kopete design discussions
4.	11 May 2002	(1 post)	Kicker usability improvements added to CVS
5.	14 May 2002 - 16 May 2002	(7 posts)	Managing Bug Reports
6.	17 May 2002	(1 post)	Keramik KWin decoration added to CVS

KDE Traffic #37 For 21 May 2002

Editor: Juergen Appel

By Aaron J. Seigo , Chris Howells , Juergen Appel and Rob Kaper