faq
flatforty
contribute
subscribe
configure
search
rdf
main
parent
|
Original Subject., or should we start a new page?
by JRT on Friday 21/Mar/2008, @13:12
|
I really hope that we don't have another problem with a SOC project like we did with Okular. People are still unhappy about it and we lost not only some good developers but their work that is now orphaned.
So, I hope that SOC can produce something new that is not a replacement for an existing application.
My suggestions are:
Karbon & Kocoa. For those that don't get it these would be toolkits to run Mac OS/X applications on any system that runs KDE.
A way for KDE to manage local printers without having to use CUPS and with PPD files like OO uses.
I would really like to see a KPart that will correctly render SVGs that are a little more complicated than the basic ones we use for Icons. Remember when we had the SVG background contest and KDE software wouldn't properly render many of the entrants. This could be done by adapting Apache Batik (which is Java). Either use JNI or see if GCJ will actually work.
We need a SMIL player (a KPart). But, what OSS really needs is a SMIL development program that can produce content as good as Flash. SMIL is almost up to version 3.0 and it is going nowhere due to a lack of software support.
IAC, please try to think of things that are missing rather than starting what can only be called an ego trip to make a new app that is better than an existing one, as opposed to making an existing app better which is a good thing.
KDE is missing many XDG desktop integration features. These don't seem significant -- just little things, but they are very important to implement. |
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Original Subject., or should we start a new pa
by jospoortvliet on Friday 21/Mar/2008, @13:25
|
Karbon & Kocoa.
Aside from possible legal issues and the fact it's probably hardly possible, it's way out of scope for a SOC (in terms of size, I mean).
The printer thing: why duplicate work which is done in a well-maintained underlying system within a desktop environment?
Would love a better way of viewing SVG, but then I'd rather see it in Gwenview so it can show SVG's like any other picture (and it already provides a KPart).
SMIL is coming, partly, in kmplayer. Maybe someone wants to help there...
Maybe the XDG stuff is interesting as well. As you seem to know a lot about it, why not take that on yourself?
|
[
Reply To This | View ]
|
Re: Original Subject., or should we start a new pa
by Dan on Friday 21/Mar/2008, @14:42
|
Any improvements to svg should go into ksvgrenderer, this will ensure that all applications using svg's get the benefits, not simply an application to display them.
|
[
Reply To This | View ]
|
Re: Original Subject., or should we start a new pa
by Dan on Friday 21/Mar/2008, @14:43
|
Err make that qsvgrenderer.
|
[
Reply To This | View ]
|
Re: Original Subject., or should we start a new pa
by JRT on Sunday 23/Mar/2008, @00:32
|
WINE more or less works and it is an attempt to reverse engineer a totally closed system. As I said, Cocoa and Carbon are well documented and a lot of Cocoa is based on code that is now opensource (gnuSTEP).
There is an old expression about using a sledge hammer to kill a gnat. I see no duplication of work a simple print system; there isn't a lot of work to duplicate in any case since I am suggesting a *simple* system for a single user to drive one or two printers.
If GwenView doesn't use the same code that SVG Part uses, perhaps there are architectural issues that need to be addressed. Yes, whatever is done it should be available in all apps.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
