The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: newbie see newbie do
by tritone on Wednesday 13/Mar/2002, @01:46
|
You call Blackbox a Desktop Environment? Hah! Good one.
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Andrew on Wednesday 13/Mar/2002, @07:14
|
I'm nowhere near a newbie; I've tried Gnome several times over the years and always it comes back to the same thing: Gnome is pretty, but KDE seems to have the integration I desire down far better and it looks "more professional."
I have trouble explaining that last part. It's very personal and very circumstantial, but to me KDE feels like it belongs in an office, where Gnome belongs on a home desktop. Maybe it's something to do with the icons, I don't know. I know that you can make the icons smaller, but Gnome's iconsets seem to thrive on being large. KDE has gon the opposite way: their icons default small and look good small. Gnome definately has speed advantages since it doesn't have to deal with the C++ relocations that KDE does, but with glibc2.2.5 and gcc3.0.4 things are really improving on that front.
As far as KDE being icky in the real world I have to disagree. While I don't like kwin at all (I use WindowMaker), the rest of KDE is very very well thought out and seems to work very well with each other. I use OpenOffice over KOffice because it's more stable and works flawlessly with MS Office file formats (reading and writing), but KOffice has some very nice features (including vastly superior printer support and font handling onscreen) -- I wish I could get the features that KOffice and OpenOffice has into one office set; that would really be nice.
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Office user on Wednesday 13/Mar/2002, @10:29
|
I think it would be a better effort to try to put a KDE interface on top of the Open Office code. How feasible would this be and would it take less work than improving KOffice?
Anyone?
|
[
Reply To This | View ]
|
Please!
by Daniel Lemire on Wednesday 13/Mar/2002, @11:42
|
KOffice is pretty good. It has got as many features as OpenOffice, but it is quite usable.
When will people stop trying to unify OpenSource projects!!!
(Plus I remind you that OpenOffice is not GPL!)
--
Daniel
http://www.ondelette.com/indexen.html - wavelet forum
|
[
Reply To This | View ]
|
Re: Please!
by KOffice fan on Wednesday 13/Mar/2002, @12:14
|
Well, not really. Think footnotes, think about the number of supported formulae in KSpread, think filters. On the other hand, KOffice has a great foundation and one can only dream of what it could become given enough developers. Seriously, there are maybe 10 developers working on KOffice. They need help.
|
[
Reply To This | View ]
|
more releases..
by yatsu on Wednesday 13/Mar/2002, @12:52
|
If KOffice would release more often, it would receive more attention. Sure, it may only be one or two new minor features in each component but still it would be appreciated and increase KOffice's exposure.
<kinda-rantmode>With a release schedule of 1 release every (off the top of my head) 5 months KOffice barely has any exposure at all. Had the developers chosen to have a minor release planned for KDE3.0 they could have gained a hell of alot of attention! But no... /me shakes head in dismay. </kinda-rantmode>
Anyway, best of luck to the KOffice developers. Your work is crucial to KDE sucess.
(don't reply and mention OpenOffice. Yes, it's good. But it doesn't blend in well with KDE. Not to mention that it is SLOW)
|
[
Reply To This | View ]
|
Re: more releases..
by ik on Wednesday 13/Mar/2002, @14:28
|
releasing often is just not possible with that few developers i fear.
|
[
Reply To This | View ]
|
Re: Please!
by cm on Wednesday 13/Mar/2002, @20:46
|
> Plus I remind you that OpenOffice is not GPL!
No, but it's LGPL. So what?
(see http://www.openoffice.org/FAQs/main_faq_new_p4.html#17)
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Evan "JabberWokky" E. on Wednesday 13/Mar/2002, @13:05
|
:: How feasible would this be
It would take a near complete rewrite and serious kludging of the existing code - the resulting source would be neigh impossible to read.
:: and would it take less work than improving KOffice?
No. KOffice is not that far from OpenOffice. Its biggest problem has been rewriting a core component (trying to find a fast, stable, flexible core for KWord) and printing. It looks like the third time is the charm, and the new KWord core code is solid, and will continue to be supported, as it inherits quite a bit from new Qt stuff, and a solution for printing across KDE has been found.
Repeat it too often, and it starts to sound like a cop-out, but if you've been around KDE long enough you'll hear the phrase "the stuff in CVS is what you're looking for". In KOffice's case, that's pretty accurate. This next release is going to be the equivelent of what MS Works was a few years ago (before they replaced it with Word): a capable suite of applications suitable for nearly all home or small office needs[1]. Unless you're doing mailmerges or serious external data-driven spreadsheets, you'll have what you need. And those will probably arrive in the next version.
[1] Minus one application that probably in hindsight should have been put off - a database. The lucky thing is that now that Qt is data aware with version 3.0, so all of KDE just got much more structured and database capable. A good database app written now will be much cleaner than one written for 2.0, and then rewritten or trashed for 3.0 concepts.
Incidently, one of the biggest red herrings is "MS Office compatability". I've been using KWord with associates using Word. KWord is very capable at importing business style documents (i.e., no clip art sprinkled through the document). I save as RTF, which Word can read easily. In business correspondance, I had to flip to abiword to open only one Word document ever (and that was a document that somebody had thrown a whole bunch of form widgets into like text boxes and dropdowns).
--
Evan
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by KOffice fan on Wednesday 13/Mar/2002, @15:22
|
Having said that, OpenOffice doesn't have a database either.
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Evan "JabberWokky" E. on Wednesday 13/Mar/2002, @22:22
|
Yes, and neither does MS Office (it's one of the things added to make MS Office Professional). Having said that, the "classic" office package back when you had a wide varity of choice was a Word Processor, Spreadsheet and Database (and sometimes an Image program). To those are now added a PIM (and light groupware) and Presentation program. Those tools cover the entire needs of 90% of businesses and people, other than a few niche apps - like Point of Sale terminals and Insurance quote programs - both of which could be built upon a good Database app.
And that last reason is why I think a good database app would be nice. But I also hold that the best time to start such an endevour is post-3.0 (which is basically now). And no, I'm not going to do it - for one thing, I don't need it, or know anybody who really does to give feedback, and that's a bad problem when writing a program.
--
Evan
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Jason Katz-Brown on Thursday 14/Mar/2002, @20:58
|
What do you mean, "data-aware"? Qt 3 has a sql module, but I don't understand what data-awareness would mean. (A db lib for KDE 2 was written, but later trashed as you said would happen.)
Jason
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Evan "JabberWokky" E. on Thursday 14/Mar/2002, @22:08
|
I mean just that - the database classes in Qt. There is QDataBrowser, QDataView and so on. Now, I have yet to test it myself, but I have been led to understand that you can attach any widget (such as textboxes, scrollbars, etc) to datasources (through Signals and Slots, I would imagine), rather than collecting all the information, translating and storing it with fixed, explicit code. (Anybody who has used Qt3's database features out there, please comment!)
Regardless, abstration of datasources, XML and SQL in KDE will allow coders to develop at the higher end and add new connectors at the lower end. This will made a KDE db application, like Konqueror, just a framework that loads views and interconnects datasources through some simple scripting. Python anyone?
--
Evan
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Mike Richardson on Friday 15/Mar/2002, @02:51
|
I've not actually written any code using Qt3's DB stuff, be we looked at it as a driver layer for Rekall.
We concluded that while its probably fine for use in a dedicated application (eg., the code explicitely knows about the tables), it just does not provide enought functionality to use for a general-purpose database front end (like Rekall or Abcess). In practice, you'd end up using it simply to pass SQL queries to the RDBMS and to get back the results. The classes like QSQLCursor are just too limited. Indeed, as it stands at present, you cannot write a gernal purpose front end without coding server specific information into the front end (ie., the front end needs to know whether the RDBMS is MySQL, Postgres, etc., and act accordingly)
Of course, you might consider this claim a call to arms :))
Regards
Mike
http://www.thekompany.com/projects/rekall
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by KHTML on Thursday 14/Mar/2002, @23:55
|
Personally, I would like to see KWord save natively in XHTML (w/compression option) so that all of its documents could be displayed by _any_ Web browser. This is a superior file format and would actually put us a leg up on MS Word which requires the extra step to save to HTML.
Using XHTML and CSS would be better than using XML since not nearly as many people are familiar with the syntax. Open Office (whose spell checking I have never been able to get working) should be using XHTML instead of XML. Both are extensible but XHTML is more common.
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Nick on Friday 15/Mar/2002, @00:25
|
XHTML is a subset of XML. There are strucutures and data that you would want in a document that XHTML cannot represent. However, using a good transform you could automatically turn an XML Kword file into XHTML. That would be a much cleaner way of doing things.
Keeping the conversion apart from the file format gives you good abstraction and it's a lot easier to maintain. If the XHTML specs change you just change the transform and not the Kword XML file format.
The whole point of XML is that you can easily defined rules to convert it. As for the syntax of XML: it's self descriptive. You read the DTD and you can understand exactly what it represents and how to validate an XML file.
XHTML is just XML with a particular DTD. The world wide web consortium has pages decribing this www.w3c.org and there are plenty of good books on the subject.
CSS is a good idea, keep the display details apart from the content. However CSS is *not* defined using XML and it's syntax is horrible. When it gets replaced with a good XML based definition then things will improve.
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Nicolas Goutte on Friday 15/Mar/2002, @14:41
|
That is not the same!
There is a big difference about a file that you could display in any browser and a file that you *could* transform to HTML.
As for KWord's DTD, it is not as self-descriptive as you are assuming it, for example <FORMAT>.
As you are telling, XHTML is well described! That is the biggest advantage! New developpers will not need to learn KWord's DTD but could have better documentation. They would only need to learn the private extension of KWord, the rest would be XHTML (modular.)
I had tried to tell that back in 2001, but I did not managed to get my position understood.
As for CSS, it will never be defined in XML, as it purpose is exactly to remove such information from XML or (X)HTML.
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Carbon on Saturday 16/Mar/2002, @00:46
|
Well, for one thing, when XHTML was designed, much of HTML's features were moved to CSS to help bring HTML back to it's original purpose, as a language to describe content in a way that seperates it from page layout. However, KWord, being a DTP, is more suited towards having these in the same unit, and CSS isn't XML anyways. Also, word processing requires control and expandability of many aspects that no version of HTML/CSS has. Some of these things are:
* Fine-grain image placement : Thats in CSS only as of XHTML 1.0
* Margin and coloration control : Also in CSS
* Typeface and properties control : You guessed it, CSS
* Embedding : KWord has the abilty to embed any properly coded KPart into it's document. XHTML has no such generic insertion mechanism, aiui.
* Frames : KWord's DTP capabilites allows for framing, that is, dividing a collection of paragraphs arbitrarily and automatically into multiple connected areas. This is good for multi-colum pages, etc. XHTML has no such capability, last I checked.
I'm fairly sure that there are other things that should be on this list that I'm forgetting. What all this means is, XHTML is not a suitable general purpose DTP or WP language. Exporting to XHTML/CSS is a good idea for web development (certainly, exporting valid XHTML would be a pleasant change from what Word does) but with a document of any complexity, you're probably going to lose, at the very least, some of your editing capabilities.
Ugh, and using propreitary XHTML extensions is a horrible idea. That would require reimplementing much of what CSS is already designed to do with XHTML, and that would be tantamount to a complete fork of XHTML. At that point, the standardization (which was the point of using XHTML in the first place) goes 'Whoosh!' down the drain.
What would (and IMO should) happen to make something generic and standardized possible is if the various OSS office suite developers were to agree on a generic XML based format. This isn't too likely to happen any time soon, though, as most of the office suites are still working on feature impelementations (Abiword, KOffice) and/or code cleanups (OpenOffice), and changing the core file format would core changes that at this stage in development, would be a complete PITA to implement.
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Nicolas Goutte on Saturday 16/Mar/2002, @12:09
|
As you are writting, what you cannot do in XHTML, you can do it in CSS.
The enhanced (former "style") mode of KWord's HTML export filter shows the way.
Frames can be done using <DIV> elements and by placing them with CSS. It is the way that I plan to use for KWord's HTML export.
The only thing so far that I have found that do not exist in XHTML are variables. But that would only mean one or two private attributes (which type of variable and which format) in a <SPAN> element.
XHTML modular explicitely allows private definitions and if you do not use them, you have only XHTML. And even if you use them, it does not mean that the result becomes not "displayable" in a browser.
Therefore the problem is not the file format itself.
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Navindra Umanee on Tuesday 30/Jul/2002, @12:30
|
Thank you for posting suspicious code here. I will keep my eye on you.
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Nicolas Goutte on Friday 15/Mar/2002, @14:31
|
I already had this idea in 2001. It was rejected by David Faure.
|
[
Reply To This | View ]
|
Re: newbie see newbie do
by Nicolas Goutte on Saturday 16/Mar/2002, @11:49
|
The reason given by David Faure was that it did not want to use CSS.
In the meantime, I have also found out that the way how KWord saves and loads its files is not in favour of a change to XHTML + CSS.
Part of the work has to be done any way for KWord's HTML export (enhanced mode). The enhanced mode ("style" in KWord 1.1) writes the files using XHTMl + CSS.
Have a nice day/evening/night!
|
[
Reply To This | View ]
|
|
Re: newbie see newbie do
by jakobk on Friday 29/Mar/2002, @04:05
|
That's a problem. KDE rocks, but monopolies are never good. Not for a long time.
|
[
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)
