At aKademy I had the chance to talk to Chris Schlaeger about SUSE, its relationship with the KDE community, his view of the Linux enterprise desktop and the speed of development of several key features in KDE (a Dutch translation can be found at Bart&David).
.imgboxrt{
border:1px dotted #000;
float:right;
margin-left:5px;
margin-right:10px;
}
.imgboxlft{
border:1px dotted #000;
float:left;
margin-left:10px;
margin-right:5px;
}
Please introduce yourself and explain your role within the KDE project.
My name is Chris Schlaeger and I'm the Vice President of Research and Development SUSE Linux at Novell. I'm a long time KDE developer and I used to be the maintainer of KSysguard and before that I worked on the previous version called KTop and I hacked on kdelibs.
Not long ago Novell acquired two companies that deal with Linux: Ximian and SUSE. While Ximian is a derivative from the GNOME project, SUSE is well known for its support of KDE. How does this all come together?
Better than most people seem to believe. Novell is committed to supporting both GNOME and KDE desktop environments in its Linux desktop. We are fortunate to have acquired a robust set of desktop technologies through our acquisitions of Ximian and SUSE LINUX, giving our customers a considerable amount of choice.
We are working on our next generation Enterprise Desktop currently called Novell Linux Desktop which will feature a KDE desktop as well as a GNOME desktop. In the enterprise market the situation is still very open regarding which desktop will have the greater following. For a Linux provider like Novell it is a great opportunity to offer both desktops to our customers and see where the market is going.
During your presentation at aKademy you mentioned that SUSE offers two product lines now:
Novell Linux Desktop and Novell SUSE Linux Personal/Professional. What are the differences between these product lines?
Novell's Linux desktop is currently still under development. We are still offering the SUSE Linux desktop, however this is based on the SUSE LINUX Enterprise Server 8 code base, which has now been superseded by version 9 (released in August of this year). This represents our business offering as opposed to our consumer product offering.
They both target very different user groups which have different requirements. We have the old traditional SUSE products which really target the private user who is using Linux at home.
The Personal/Professional versions are consumer products targeted at home users. Users who either want to do very little or very specific work with their PC like writing email, surfing the web, word processing, spreadsheets, printing and the like. For those people we have the Personal version. The Professional version is basically the swiss army knife of Linux. You've got everything in there that we feel is of some interest and benefit to our customers. Both products have a comparatively low purchase price and are therefore very cost effective.
We provide security updates for a period of 2 years for these products which is something customers tend to forget. There is a lot of work that needs to be done to keep the products secure during their lifetime. A new version is released roughly every six months.
However, in the enterprise arena 2 years doesn't cut it as people want 3 or 5 years support at minimum. So for the enterprise customers we created a new product which was called SUSE Linux Desktop. The next version will be a Novell Linux Desktop which will be based on the SUSE LINUX Enterprise Server 9 code base and combines the best of SUSE LINUX Desktop and Ximian Desktop. It will have a lifetime of around 18months and we guarantee to provide support and maintenance for the product for up to five years. Also the quality assurance is much higher. In an enterprise arena you need to do integration tests to a much higher degree and we test extensively so that we don't inject any side effects when we provide fixes. That's the main reason why the enterprise versions are more expensive and also the software collection is more targeted to the needs of the customers we try to address.
What do you think are the strong points of KDE as an enterprise desktop?
KDE is a very good enterprise desktop environment and it offers all the functionality you would expect nowadays from an enterprise desktop. So from a desktop perspective it is ready. But there are still missing features on the application side. People expect more and there are some areas like the OpenOffice.org integration and the browser question that needs to be resolved.
Also accessibility is one of the hot topics where more work is necessary. But when there is a good foundation we can build on and a lot of work is being done in all areas to improve KDE. Also I'm very glad that the KDE team recognizes the enterprise market as a very important target audience they have in mind when they write software.
Could you tell me any typical enterprise features of KDE you are using?
One of the features for example is the Kiosk lock down mode. That's clearly something you normally wouldn't use in a home setup. Well maybe you want to restrict the ability of your kids to do certain things ton your PC. That is also a way to use the Kiosk mode. But primarily the Kiosk functionality is meant for use as an information terminal or on the corporate desktop where the system administrator just wants to expose the necessary functionality to the users.
Novell also has its own ZENworks. Are there any plans to integrate ZENworks with KDE ?
ZENworks is an enterprise management console. ZENworks was originally written for Windows and now
the next version called "ZENworks for Linux" will also support Linux. It is a complementary tool and is
the tool that administrators use for mass administration. So it does software inventory management and
it *controls* the lockdown. ZenWorks does not provide the actual lockdown functionality, but it
provides the configuration values. On the client you would need the counterpart that actually knows
how to implement the values that ZENworks has.
There have been some rumours, corroborated by some CVS commits, which show work going on in KDE-PIM on a configuration wizard for the Novell Groupwise client. Also the aKademy interview with Will Stephenson talks about the integration of Groupwise functionality in Kopete. Can you elaborate more on this?
We are working on the integration of KDE tools in the other products from Novell. Groupwise is the most prominent of these and is a collaboration tool that offers messaging, calendar and mail services to the user. You can now use KDE tools such as Kopete together with the Groupwise messenger and you can use Kontact to access the corporate calender and address-book and also for email.
Just curious, how long did it take to program the Novell Groupwise integration into Kontact, Kopete and KAddressbook, and how many people were involved?
It was quite amazing that we were able to do this. The messenger integration was done by Will Stephenson in 2 months. Even more surprising was the integration of Groupwise into Kontact. In less than a week developers got it running. We were able to exchange data from the server to the client. Sure, there are still bugs in there and we need to iron these out but I'm glad that it was done so quickly. I'm sure we can get it ready for the next deadline for the Novell Linux Desktop.
How will this evolve with regard to KDE and who will maintain this stuff?
We have some KDE people on board and we currently have an offer on our website for a KDE developer, especially for the KDE-PIM area. One of the tasks would be to maintain the Groupwise and messenger integration.
During your talk at aKademy you said we needed fewer toolkits. What do you mean by that?
Linux is plagued by too many toolkits. We've got Tcl/TK, Java, Motif, Athena Widgets or the old X toolkit, GTK, and Qt, and all of them look and feel totally different. Applications written in those toolkits do not follow the same standards and guidelines and are a mess to use. Especially if you have them side by side or you need to use them frequently.
Some of toolkits do not really cut it today. There is little support for accessibility, there is hardly any support for hotkeys. We just need to get rid of them. It was great that they were there and they served their purpose but I personally would like to see as few toolkits as possible in the future. They are still projects that come with their own toolkit like Mozilla and OpenOffice.org. I'm sure we can find a solution there that these toolkits can integrate and behave very well with the rest of the desktop.
During aKademy the Accessibility Forum and Usability Forum were very successful. What is your opinion about these disciplines, and how should they fit into the KDE development process?
I think it is important especially because the most interested enterprise customers we have are government agencies and they have strict rules on accessibility conformance (section 508 is mandatory in most of the US in the government agencies). If we want to get involved in that market then we need these features and they are not there yet. So I am glad that there is work going on in these areas and SUSE is a very active contributor. For instance, we have a blind developer on our team who did the first support for braille displays. SUSE Linux was the first distribution not only usable but also installable from scratch by a blind person using YaST in text mode. Of course text mode is fairly easy compared to graphical user interfaces and having a good off screen model and screen reader is a significant amount of work. Trolltech and Sun have done really a lot of work in this area and we really hope that with Qt4 and KDE4 we can profit from this and offer this technology to users.
What will Novell/SUSE do to improve the experience on the desktop?
We are working on OpenOffice.org to make it integrate better with the desktops. On SUSE 9.1 you saw already the first fruits of this work - if you start OpenOffice.org it looks like a KDE application. It is a first step but it is far from complete: if you open a file you get a totally different file dialog that is not only awkward to use, but also doesn't fit into the KDE look and feel. The same for printing. That is still something we need to overcome but we are working on this and probably will have better integration with the next product.
So that's one piece of the experience on the desktop, the OpenOffice.org part is there. Something going on with the Mozilla browser part as well?
Well that started on aKademy where we discussed this on the first day. The question came up during a discussion I had with Matthias Ettrich and a few others. It is currently a pain to the user to need two installed browsers, one browser which works for this website and the other browser which works for the other website. Konqueror is fast and nicely integrated, but Mozilla renders more pages better.
Customers that do web application development heavily use DHTML and other special features that Konqueror doesn't handle very well and it is a lot of work to implement this. Although I like KHTML and the architecture quite a bit I am sad to say that probably the Gecko rendering engine will be the dominant one used in the enterprise arena, and as KDE developers we've got to make sure that we can integrate Gecko fairly well into KDE.
So Lars Knoll and Zack Rusin started working on this at aKademy and I was delighted when they put me aside and showed me what they have done in just three days. It is amazing! I think it is the right way to go! It is a bit sad for KHTML and I hope that despite this people will still maintain it as it is a nice lightweight browser. If it would be a purely technical decision, KHTML has the better architecture, but sometimes you need to go the shortest way to get to your target.
What about technology like D-BUS (the Desktop Bus) and HAL (the Hardware Abstraction Layer)? What are your thoughts on that?
I think D-BUS will come probably with KDE4, not earlier than that. It is a lot of work to implement that properly but I think it is going in the right direction. We need to integrate the desktop and the operating system much deeper. So that you can control the hardware on the desktop or have the right feedback on the desktop.
If I connect a camera currently I get a nice icon on the desktop where a Konqueror browser is opened. SUSE has that for quite a while, but if you look at how we implemented this ... It is a real pain and doesn't work 100% reliable. The problem is with the hotplug system of the underlying OS and the way we have to communicate those kernel events into userspace. D-BUS hopefully will solve some of these problems in the long run. It is a lot of work but it is going in the right direction and I'm sure we will adopt that.
Do you think the KDE desktop should ready itself for that kind of technology?
I think that there is a general understanding within the KDE developer community that D-BUS is the right way to go. Not for KDE3 but probably for KDE4.
Currently we have developers, translators and documentation writers as part of the KDE development process. How do you think other disciplines like accessibility and usability should participate in the development process?
I think they should participate and the KDE project should adapt their structures to integrate those groups as well. It is important to have their work integrated but that is something you should ask the KDE release coordinator to see how we can fit these people into the process. But for example, who could have imagined that we would have more then 50 languages in KDE? Surely this will also happen to other areas like accessibility and usability, as there is some good work going on to get people involved.
Where would you like to see the future of KDE go, and what new features would you like to see in future releases?
KDE has made tremendous progress over time. I joined the project when it only had a few dozen people and now it is 700 people strong and is constantly growing, and the enthusiasm of the project hasn't decreased at all. It is now not only working on the core part but also working on parts like accessibility, translation to many languages, documentation work, artwork and other areas which are not directly linked to the core code-hacking. I'm glad this is going on and we need more of this in the future. We need more applications in the future, and good accessibility support, OpenOffice.org integration and the browser problem are the most practical features would like to see in the next release.
How will the relationship between Novell and KDE evolve?
I'm sure that we are going to sponsor KDE development in the future. We have (I think) sponsored every major KDE event, like we did with aKademy this year. So why should we stop now?! Novell is very much committed to KDE!
Comments
Please excuse me but what is up with all the OOo obsession ? In the previous article (the Interview with David Faure) someone pointed out how many problems he got with OOo by rendering Tables wrong, Segfaulting when loading old Staroffice files, the huge load times and the overall slow and bad operation. I don't think that Enterprise customers want that. Not to mention that the entire Staroffice suite (afaik) is written using the Staroffice foundation class. Totally different to what QT or GTK+ is and altering everything to use a GTK+ or QT Window or Filedialogs doesn't change the rest of the program. It's a lot of energy and time that could be better used to finish KOffice for example.
Gecko vs. KHTML part in this Interview also sounds like it would be better to abandon KHTML in favor to Gecko. Sure Gecko does offer better rendering capabilities but its entire framework doesn't really fit into the KDE or GNOME world. Speaking of XUL as different Widgetset or the entire Interfaces for JavaScript, SSL, Cookies etc. This would require a lot of work on the KDE side I assume and would only generate a huge mess (which I only assume here).
HAL and DBUS also something that needs to be thought about. HAL, as the name implies it's a Hardware Abstraction Layer and we know that BSD, Linux, Solaris and so on offer their own Kernel side HAL which sits between Hardware and Kernel. This new HAL (god bless but it's all against what I have been studying for many Semesters) is something I don't understand this one sits between Kernel and Desktop in Userland and adds a second HAL layer ontop of it working together with UDEV and Hotpluging. Either I don't understand it, or it's totally different to what people teach students at universities or last but not least the name is misleading.
DBUS something that has been created by the GNOME fraction once they realized that CORBA and Bonobo is overkill for what they do now trying to get the KDE people to throw away DCOP in favor of this.
Parts of the Interview gives me the impression that this guy is more talking for the side of the GNOME people rather than the KDE people because everything he said I already heard from GNOME and de Icaza. This is exactly what the GNOME people are doing. Merging OOo, merging HAL, merging DBUS, merging Gecko and everything that has been done so far looks like unfinished patchwork. I don't think or believe that this is what KDE users and supporters really want. Sure they want good functionality such as good rendering and good office suite but this doesn't mean that KDE has to throw away half of their core for things that can hardly been merged due to different framework.
When I listen to the kde-core-devel mailinglists then I see how people defend the position and questionize whether HAL, DBUS, Gecko are all that good of ideas. Hell whenever some GNOME fart into the air we need to adopt it. They say jump and we have to jump.
OOo is a current necessity given the state of other options. i do hope that in the long run it goes away, and having KOffice use the OOo file format natively puts it in a good position to take over eventually.
as for HAL, DBUS and other such things, stop obsessing about where things come from. as long the license is right (e.g. Free/Open Source), the only the question we need to ask is "Would using this make KDE better? Does it serve our goals and purposes?" for what else really matters? these are complex questions that cover everything from features, release cycles, APIs, interop, maintainability and much more. but "did a GNOME touch it?" is irrelevant.
as for "unfinished patchwork", well.. if that's your assessment of the GNOME's efforts, fair enough, but i fail to see how their efforts reflect upon our's, anymore than our's reflect upon their's. i'd suggest judging the KDE project's efforts by the KDE product, not some other product.
"Hell whenever some GNOME fart into the air we need to adopt it." you mistake cooperation for weakness and brand it undesirable. cooperation goes both ways (look at how many freedesktop.org specs are basically KDE ideas touched up and 'rebranded'), and it can have great rewards for all, especially our users.
now, mindless acceptance of any and every suggestion would be stupid. but fortunately the KDE developers are anything but mindless.
I totally agree. Using OOo brings to mind the expression 'don't look a gift horse in the mouth'. Without it large Linux deployments wouldn't happen. It is nice to see the active development in KOffice.
Regarding DBUS (and other technologies that Kde would adopt), the question is whether the developers are responsive to the needs and suggestions from the Kde folks. From what I understand, there is no problem.
Derek
Hi,
Even though I understand your point, 'don't look a gift horse in the mouth' seems like a terrible choice as an expression to me. If it's important as a selling point right now, then it should be examined closely. If KDE integration is important this kind of things simple cannot happen: http://qa.openoffice.org/issues/show_bug.cgi?id=23526
Drag and Drop of images from konqueror to some of the OpenOffice.org apps (e.g. OO Writer), create a link to the image instead of including it. This can be terrible, it affects KDE users directly. It screwed up lots of documents of my sister which were filled with pictures. I reported it almost one year ago. I'd expect at least, lots pressure from distros like SUSE towards the OO.org developers to fix this kind of nasty bugs.
My sister is now using KOffice for that kind of work.
Well, OOo is currently necessary. It more or less imports and exports most MS Office files without problems, it has a lot of features, it doesn't crash.
Big downside: slow and huge.
Gecko, well, I don't know, KHTML is cool.
DBUS: this has the potential to become really cool. It doesn't come from GNOME. It doesn't even link to glib. It will make KDE startup faster (since it's already running at that time and doesn't have to be started like dcopserver). Kernel messages (e.g. hotplugging) might come via DBUS. We will be able to talk to KDE and Gnome and apps via DBUS.
Bye
Alex
What do you mean it doesn't have to be started? As far as I know a DBUS server is started for each user, in addition to the system DBUS server.
I guess it will be started by default when the user logs in, so it's already there when the KDE startup starts. Or if you are running a gnome desktop and start a KDE app then it will be already running.
Bye
Alex
about that hal stuff. from what i understand the linux kernel have a hal in only the strictest sense if at all. the "hal" i belive is that you will find a cdrom under /dev/cdrom if you have the system set up nicely, or under /dev/hd** if you dont...
for devices like digital cameras, webcams and so forth your app will still have to understand what is comeing out of the device file for it to be usefull. the hal in the works is supposed to be a bit like directx. you code towards it and it will then act as a translater between the device and the app. hell it may even help in allowing access by multiple apps if needed...
| about that hal stuff. from what i understand the linux kernel have
| a hal in only the strictest sense if at all. the "hal" i belive is
| that you will find a cdrom under /dev/cdrom if you have the system
| set up nicely, or under /dev/hd** if you dont...
...or under /dev/pcd* if it is a parallel port cdrom, or under /dev/cm206cd if
it is a Philips LMS CM-206 cdrom, but for the Philips LMS CM-205 you need to
look out for /dev/cm205cd... and so on and so on. The (Linux) kernel exposes
devices as a loose bag of drivers, device nodes and buses. For the
application developer is it a nightmare to make sense of, and it keeps on
changing as new hardware support is added. HAL solves this problem by
organising and reporting all of the hardware that you have in a form designed
with applications in mind. This is how HAL reports my cdrom:
udi = '/org/freedesktop/Hal/devices/block_22_0'
info.udi = '/org/freedesktop/Hal/devices/block_22_0' (string)
storage.hotpluggable = false (bool)
storage.cdrom.write_speed = 2816 (0xb00) (int)
storage.cdrom.read_speed = 7040 (0x1b80) (int)
storage.cdrom.support_media_changed = true (bool)
storage.cdrom.dvdplusrw = false (bool)
storage.cdrom.dvdplusr = false (bool)
storage.cdrom.dvdram = false (bool)
storage.cdrom.dvdr = false (bool)
storage.cdrom.dvd = false (bool)
storage.cdrom.cdrw = true (bool)
storage.cdrom.cdr = true (bool)
storage.removable = true (bool)
storage.firmware_version = 'OS0B' (string)
storage.drive_type = 'cdrom' (string)
info.product = 'LITE-ON LTR-16102B' (string)
block.storage_device = '/org/freedesktop/Hal/devices/block_22_0' (string)
storage.physical_device = '/org/freedesktop/Hal/devices/ide_1_0' (string)
storage.vendor = '' (string)
storage.model = 'LITE-ON LTR-16102B' (string)
storage.automount_enabled_hint = true (bool)
storage.no_partitions_hint = true (bool)
storage.media_check_enabled = true (bool)
storage.bus = 'ide' (string)
block.minor = 0 (0x0) (int)
block.major = 22 (0x16) (int)
info.capabilities = 'block storage.cdrom storage' (string)
info.category = 'storage' (string)
info.parent = '/org/freedesktop/Hal/devices/ide_1_0' (string)
block.device = '/dev/hdc' (string)
block.is_volume = false (bool)
block.have_scanned = false (bool)
block.no_partitions = true (bool)
linux.sysfs_path_device = '/sys/block/hdc' (string)
linux.sysfs_path = '/sys/block/hdc' (string)
info.bus = 'block' (string)
All of the vitial information is broken down and organised reguardless of where exactly it came from.
--
Simon
"and questionize whether HAL, DBUS, Gecko are all that good of ideas."
I mean, with well-written and founded statements like that, how can anyone arguize?
Although I don't like people making fun of (I assume) non-native writers of English that one made me laugh.
I agree with your view regarding OOo and Gecko. They're both bloated monstrosities and don't really fit into KDE. But sometimes I have to use OOo because Koffice is just not there yet. For instance, have you ever tried to produce nice charts from your spreadsheet in kspread and then tried to print them? I gave up and went to OOo Calc for that. But, what I can't do with OOo is control it with scripts via DCOP! This is the greatest asset KDE has! I use it quite frequently, for instance to fill in spreadsheet cells and other stuff.
Regarding Gecko and KHTML, some of our users found out that Konqueror renders some pages just fine which Mozilla/Firefox just balk on. And after I showed them the DCOP-Kaction bridge and how to use it to script Konqueror they got completely hooked. The challenge was to save copies of certain pages automatically and neither wget nor curl could do it because of some javascript stuff in the page. With Konqueror and DCOP it was childs play. So, before you through away DCOP and replace it with DBUS please make sure that KDE doesn't loose any of the current DCOP functionality! This is one of the main selling points for KDE IMO.
SUSE 9.2 was just announced by the way :)
http://www.suse.com/en/company/press/press_releases/archive04/92.html
The absence of any mention of a Personal version is "interesting".
It's not. There is no SUSE 9.2 Personal edition.
I'm glad, 9.1 Personal Edition was an abomination to me :)
SUSE 9.1 Personal was KDE only with Kontact, Konqueror, KDE/OOo. So I guess Novell put a stop to that.
Or it didn't pay off the additional efforts (creation, handbook, package, shipping, advertizing) for it. Note that if it's all but the first of this reasons there may be still a downloadable version as currently under different name.
well .. it's the first press text from SuSE mentioning two Desktops in the order "blah... SuSE Linux 9.2 includes"
"Gnome and even KDE"
with 9.1 it was
"KDE and even Gnome"
the things they are a changing...
Huh?
in the short version as well as the long version it's "KDE 3.3 and GNOME 2.6 desktop". Furthermore the order of development tools is "KDevelop, Eclipse and Mono,". I think that's pretty clear ...
I'm very excited about the prospect of Mozilla as a Qt app. Better integration is always good--and I'm hoping that perhaps it also fixes some of the suckage in Mozilla's printing system.
Well, you can always hope...any chance of a KFirefox?
>Well, you can always hope...any chance of a KFirefox?
Yes ;-)
http://www.kdedevelopers.org/node/view/615
what he is talking about is no Kmozilla. you will still be using konqueror, and you wont be noticing you're using Gecko, Mozilla's rendering engine, instead of Khtml. except that its slower, of course, and bigger, of course, and it renders a few pages better.
I'd say offer it as an option. Macintosh choose Khtml over Gecko, they are enhancing Khtml, I think gecko is not the right choice for suse. they should maybe cooperate with Macintosh for enhancing Khtml.
Apple choose Khtml over Gecko. Macintosh was just an Apple product. ;)
I'm coming from a Gnome background. Still I think I like the khtml engine more than Gecko, mostly because it's smaller.
What I don't understand is that, for some time now, in KDE you have been able to simply choose your renderer, which is KHTML by default. I know a lot of people talk about changing it over to Gecko because they prefer it, but the interview made it sound like Konq coul only be used with KHTML. What's up with that, and why is it "so much work?"
you was only able to choose between KHTML and Opera's engine, Gecko was not possible. it is now.
I think the great point using gecko is to get the XUL technology working soon on KDE and compete with the future MS Avalon strategy.
As one of those bystanders of us who don't read the dev lists, I'm confused.
Apple seems to be using Safari quite well, and I'm assumming that will be their "Enterprise" browser. Yet this interview seems to suggest dropping KHTML in favor of Gecko.
So what is apple doing differently? Are they actually doing more developement that is not trivial to roll back into KHTML? (For that matter apple stated that they used KHTML instead of Gecko because it was easier to code for and a cleaner, lighter code base).
I run kde on the desktop but use Firefox mainly because gmail works with it (wow, gmail also works with safari).
This just seems silly to me....
Short answer: There are no Safari patches.
Long answer: There is no shared resource for KHTML/KJS's source code, instead Apple decided to develop KHTML/KJS further in house and releases them as WebCore/JavaScriptCore. There never were and still aren't enough developers working on KHTML/KJS to really keep up with all the changes done by Apple which aren't available as patches nor are documented. And today the sources for both versions are different enought to make "back merges" non-trivial. Now most improvements on KHTML are done more or less completely by KHTML developers on their own, just taking a look at WebCore or Gecko to see how particular issues are solved there. As one developer noted on a mailinglist regarding this topic, solving problems on your own is way more interesting than trying to merge two increasingly different source bases. However I'm sure people looking at merging more Apple improvement into KHTML/KJS are always welcome.
You see there are many areas where KDE could make good use of more developers.
Interesting way for a company to take advantage of open source.
Take a (l)gpl'ed product and fork it so fast that the original developers can't keep up with it.
It seems like a shame and contrary to the spirit of open source. (Let's hope MS doesn't learn too much from apple ;) )
> Interesting way for a company to take advantage of open source.
> Take a (l)gpl'ed product and fork it so fast that the original developers can't keep up with it.
I don't think that's a fair evaluation. Ask some rational questions. What is Apple supposed to do after they have made their changes? Wait for KDE developers to catch up before the make any more? There are several things we want from webcore to use with Quanta, but it just looks like a long time before a lot of them can be brought in and it's no simple merge.
Open source is a marvelous thing, but unfortunately for a lot of people it's a mythical concept that works this way... Because the source is open zillions of developers constantly review and update it. Of course a "zillion" is a fictitious number and therein lies the truth. A remarkably small number of developers, as in a tiny fraction of a percent of all users, do an amazing job of producing software. Even the percent who "contribute" by griping is remarkably small. ;-)
Consider the numbers... KDE has millions of users, hundreds of developers and how many core applications? Do the math. Better yet learn to code. ;-)
The nice thing would be to send the changes back as a series of patches, or atleast keep openly track of changes in their release, so we had a kind of changelog. Currently we have no idea of whether or not a bug is fixed in WebCore, or when we spot a change what is supposed to be good for.
I dont understand why they dont help... they where quite cooperative, the first time they did sent patches or at least a comprehensive list of changes, did they?
They still release a comprehensive set of changes in each version of Webcore, but most things rely on other things to be merged. And merging is very hard to do right without breaking stuff. A shared code base would probably been the best thing to do in hindsight. @ a khtml.org or something.
So does this mean that the Safari/khtml thing is screwed? Do we bascially have two seperate code bases that don't crossover at all? What need to happen to get these two groups working together again? Gecko is ok, but from a design standpoint khtml is far far superior and I just hate to see what could be one of our best deverlopment resources waisted.
Bobby
Pretty much all developers working on KHTML also/mainly work on other areas within KDE, while KHTML definitely needs someone to focus on it full time (and doing so within KDE, not for Apple). When looking on CIA (see some posts further down this page) the only one who seems to work on KHTML exclusively is Germain Garand, someone should hire him to let him do so full time. =)
I think it is a very fair evaluation, to be honest. It's well known how to have corporate hackers work well with volunteer hackers, it's done in open source projects like the kernel, Wine, and yes KDE/GNOME all the time. You send back patches in series, with a detailed changelog. You should develop those patches in the open, with discussion on the mailing lists.
In other words, you do not do what Apple has done - effectively fork the codebase in secret and then give the original developers a huge unworkable patch dump. I've had to deal with such things from TransGaming in Wine and they're basically useless, especially as often they duplicate code already written by volunteers and usually nobody understands the changes except developers who aren't in the community. The way CodeWeavers does it is *much* preferable (disclaimer: I am biased, I work for CodeWeavers. But I wouldn't work for them if they didn't interact with the community well).
To be frank it doesn't surprise me that KHTML has forked, Apple clearly have no interest in working with the community on it and demonstrated this from the start. They fulfill their legal obligations and do no more.
Thanks again for your answer-
A couple more questions:
Where are the mailing lists? (If you have the link to the developer you mentioned that would be great)
Also is it possible to do the same thing they did to us back to them? (Basically take their fork and wrap it back in as a KHTML replacement. Call it KHTML2.0 or something.)
It just seems like there should be some sort of expose on this. Someone needs to put a writeup in a blog somewhere and get /. or osnews to link to it.
> Where are the mailing lists?
https://mail.kde.org/mailman/listinfo/khtml-devel
https://mail.kde.org/mailman/listinfo/kfm-devel
Of cause it's possible to take as much of Apple's WebCore/JavaScriptCore source code as you like and do what you want with it. Create a KHTML 2.0 with it if you want.
However, the problem is not down to access to the code, or any kind of legal obstacle, it's purely man hours (or the current shortage of) on the KHTML devel side. That's not Apple's fault.
You seem to think that Apple should write for two different sets of source trees, just because they took the Open Source code from KDE in the first place. Why should they do that? They didn't ask the KDE team to re-write KHTML for them in the first place so they could easily integrate it into OSX. They did all the leg work themselves. Now they've merged that code into their own framework, and that's the framework they're writing to. The source code for WebCore/JavaScriptCore is Open Source, so others can take that and make use of it for themselves if they want to. That can be the KDE team, or someone completely different. That's what Open Source means!! What it doesn't mean, is that you have to write someone else's applications for them, as you seem to want.
>I run kde on the desktop but use Firefox mainly because gmail works with it
From what I've read on the lists, gmail should now work on konqi too (http://lists.kde.org/?l=kfm-devel&m=109690082612439&w=2). Are there any more problems? Is it worth building kde cvs?
Good to see its being worked, it would've been bad had GMail gone out of beta with no Konqueror capability in sight.
I pretty much just use Firefox now, which is annoying since some things (like saving a file without having to open a file save dialog) is easier in Konqueror.
this thread might be interesting to read: https://mail.kde.org/pipermail/khtml-devel/2004-July/001068.html
No, that's not true. People just got this whole thread wrong. Enterprise is not Gmail. Enterprise is for example, among others, SAP. SAP doesn't support Safari/KHTML. SAP supports Mozilla. The story ends.
And gmail also works with KHTML now.
gmail fixes went in this week.
Derek
I really don't understand it when people claims that Gecko renders pages better than KHTML. Most webpages looks better in KHTML than in Gecko on my desktop, as long as KHTML does not choke on the HTML. As I see it, this is because of more "compatibility patches" in Gecko and wider acceptance in webmaster circles leading to less incompatible HTML and JavaScript using it.
But KHTML is surely the superior renderer from an aestethic POV.
I use Firefox mainly for my webbank, because of the lack of support for secure java applets in konqueror. I also use Firefox on rare occations when pages i need to use is giving Javascript problems. Apart from that I'd prefer Konqueror anytime.
> lack of support for secure java applets in konqueror
Hu? http://www.konqueror.org/javahowto/ "Getting HTTPS support for Applets"
The HOWTO is out of date. It refers to ancient java versions. It seems that I need to install the java sdk from sun, which I'm now trying, since sun jdk 1.4.2 does not seem to conatin the required files. The jsse page at sun claims that it has been integrated with the 1.4 sdk. Eeew, HUGE downloads probably for nothing :(
But I try.
Yes somebody should update that docu :-).
Btw. in kde > 3.2 if you enable 'Use KIO', the jsse isn't used because KIO download all code then.
Btw2. secure applets can also mean that these applets should get more privileges than 'normal' ones, like accessing you hard drive. There is some code for it in kde 3.3, but not finished and hardly tested. (If someone wants to give a helping hand, like the certificate chain verification, that would be really nice)
Being a webmaster myself I believe I have the expertise to tell about the quality of rendering. Stating the KHTML renders better then Gecko is only proof that you have never created a CSS-based site for KHTML. They still have *way* to go before the CSS engine will become really useful.
It took us *weeks* to find workarounds for KHTML's weaknesses. You can not seriously state that KHTML renders better then Gecko.