This past summer there was a discussion about deprecating KOffice. Fortunately this plan was abandoned. KOffice includes the following apps:
KWord: Word Processing KSpread: Spreadsheets KPresenter: Slide Presentations Karbon14: Scalable Graphics Drawing KPlato: Project Management Kexi: Database Creator Kugar: Database Report Generator KChart: Chart and Graph Creator Kivio: Flowchart and Diagram Editing Chalk: Painting and Image Editing KFormula: Formula Editor
If this suite is advertised as a personal office suite rather than professional the apps remain viable for many Trinity users. The tight integration with TDE is a bonus too.
I hope KOffice is not removed from the Trinity line, but I am wondering how much work is involved to package the apps separately. Likely there would need to be a koffice-base package that contains all the common libraries, headers, etc.
I seem to recall once upon a time the developers for one of the distros doing this, but my memory gets fuzzy these days. :)
Is separate packages feasible and doable?
Just asking. :)
Darrell
On Monday 21 November 2011 09:26:04 pm Darrell Anderson wrote:
This past summer there was a discussion about deprecating KOffice. Fortunately this plan was abandoned. KOffice includes the following apps:
KWord: Word Processing KSpread: Spreadsheets KPresenter: Slide Presentations Karbon14: Scalable Graphics Drawing KPlato: Project Management Kexi: Database Creator Kugar: Database Report Generator KChart: Chart and Graph Creator Kivio: Flowchart and Diagram Editing Chalk: Painting and Image Editing KFormula: Formula Editor
If this suite is advertised as a personal office suite rather than professional the apps remain viable for many Trinity users. The tight integration with TDE is a bonus too.
I hope KOffice is not removed from the Trinity line, but I am wondering how much work is involved to package the apps separately. Likely there would need to be a koffice-base package that contains all the common libraries, headers, etc.
I seem to recall once upon a time the developers for one of the distros doing this, but my memory gets fuzzy these days. :)
Is separate packages feasible and doable?
Every distro I've used made KOffice in separate packages. Also, if you look on the page for downloading the source code, you'll see it separated under "applications/koffice".
Awhile back during my initial switch to Linux, I remember it having poor support for MS Office. Also, I don't know if it can use more recent versions of ODF (there were a couple newer revisions to the ODF spec added to OOo/LO). The 3rd complaint is that when I used it awhile back, I don't remember seeing a way to switch it to a interface similar to OOo/LO. Whilst I'm sure people like the simple wizard that it uses, I personally don't. This would be a definite feature request :-)
On Tuesday 22 November 2011 03:26:04 Darrell Anderson wrote:
If this suite is advertised as a personal office suite rather than professional the apps remain viable for many Trinity users. The tight integration with TDE is a bonus too.
absolutely, yes. I like kword and kspread well, ligthtweight, fast, well integrated, does (nearly) every thing I need, so far. some quirks though (inconsistent font sizes, e.g.). (I also tried koffice2.x several times, before it became calligra, and it was a complete mess, unusable, data loss etc.). OO, however, is a monster and just plain overkill, I just use it rarely when I have to look at some M$-office documents sent from someone...
I hope KOffice is not removed from the Trinity line, but I am wondering how much work is involved to package the apps separately. Likely there would need to be a koffice-base package that contains all the common libraries, headers, etc.
hm, there ARE separate packages, e.g. kspread:
aptitude show kspread-trinity
Paket: kspread-trinity Neu: ja Zustand: Installiert Automatisch installiert: ja Version: 4:3.5.13-0debian9+r1260139+pr4~squeeze Priorität: optional Bereich: kde Verwalter: Timothy Pearson kb9vqf@pearsoncomputing.net Unkomprimierte Größe: 8.303 k Hängt ab von: kdelibs4c2a-trinity (>= 4:3.5.8-1), kexi-trinity (>= 4:3.5.13), koffice-libs-trinity (>= 4:3.5.13), libc6 (>= 2.3.6-6~), libgcc1 (>= 1:4.1.1), libice6 (>= 1:1.0.0), libpng12-0 (>= 1.2.13-4), libqt3-mt (>= 3:3.3.8-d), libsm6, libstdc++6 (>= 4.4.0), libtqtinterface, libx11-6, libxext6, zlib1g (>= 1:1.1.4), koffice-libs-trinity (< 4:3.5.14) Empfiehlt: khelpcenter-trinity | koffice-trinity-doc-html (= 4:3.5.13-0debian9+r1260139+pr4~squeeze) Beschreibung: a spreadsheet for the KDE Office Suite [Trinity] KSpread is a powerful spreadsheet application. It is scriptable and provides both table-oriented sheets and support for complex mathematical formulae and statistics.
This package is part of the KDE Office Suite. --
what's missing from koffice in trinity, are all localisation packages, though.
werner
If this suite is advertised as a personal office suite
rather than
professional the apps remain viable for many Trinity
users. The tight
integration with TDE is a bonus too.
absolutely, yes. I like kword and kspread well, ligthtweight, fast, well integrated, does (nearly) every thing I need, so far. some quirks though (inconsistent font sizes, e.g.). (I also tried koffice2.x several times, before it became calligra, and it was a complete mess, unusable, data loss etc.). OO, however, is a monster and just plain overkill, I just use it rarely when I have to look at some M$-office documents sent from someone...
I think our approach must not focus on MS compatibility. That is a hill far too steep to climb. Not even the OO/LO people have achieved that --- and they never will. Every time I test importing complex Word documents into OO/LO Writer they look broken. I'm talking complex documents, not simple letters and memos with manual formatting. :) I have no hope of any free/libre word processor having full compatibility with MS Office --- nor do I care. The TDE team should focus "marketing" efforts on KOffice as a personal office suite. Ignore the compatibility discussions.
Because of our recent discussions about maintaining Trinity user guides, I have been looking into what KWord can actually do. I never used KWord. Yet as I read more about KWord I am finding the feature set palatable for personal use.
With respect to sharing files created in KOffice, the compatibility bridge is resolved by printing documents as PDF, which the underlying TDE print engine supports. Importing files is another issue, but if users realize they can print to PDF perhaps they will demand others do likewise. I have done this professionally too. I use an old version of MS Office and when people send me a docx file I tell them to try again. Guess what? They do. :)
I want to spend several days using all of the KOffice apps in a focused manner to develop a more healthy opinion about what is provided.
Somebody mentioned ODF support. We might need to ensure ODF support is up to date.
Tim, if KOffice ODF support is lagging, can we add that as a candidate for R15 (not R14 --- R15)?
I hope KOffice is not removed from the Trinity line,
but I am wondering how
much work is involved to package the apps separately.
Likely there would
need to be a koffice-base package that contains all
the common libraries,
headers, etc.
hm, there ARE separate packages, e.g. kspread:
aptitude show kspread-trinity
Well, then. Looks like I need to learn how to package the apps separately. Can anybody here help with that? A mini how-to?
Darrell
On 22 November 2011 12:06, Darrell Anderson humanreadable@yahoo.com wrote:
If this suite is advertised as a personal office suite
rather than
professional the apps remain viable for many Trinity
users. The tight
integration with TDE is a bonus too.
absolutely, yes. I like kword and kspread well, ligthtweight, fast, well integrated, does (nearly) every thing I need, so far. some quirks though (inconsistent font sizes, e.g.). (I also tried koffice2.x several times, before it became calligra, and it was a complete mess, unusable, data loss etc.). OO, however, is a monster and just plain overkill, I just use it rarely when I have to look at some M$-office documents sent from someone...
I think our approach must not focus on MS compatibility. That is a hill far too steep to climb. Not even the OO/LO people have achieved that --- and they never will. Every time I test importing complex Word documents into OO/LO Writer they look broken. I'm talking complex documents, not simple letters and memos with manual formatting. :) I have no hope of any free/libre word processor having full compatibility with MS Office --- nor do I care. The TDE team should focus "marketing" efforts on KOffice as a personal office suite. Ignore the compatibility discussions.
Because of our recent discussions about maintaining Trinity user guides, I have been looking into what KWord can actually do. I never used KWord. Yet as I read more about KWord I am finding the feature set palatable for personal use.
With respect to sharing files created in KOffice, the compatibility bridge is resolved by printing documents as PDF, which the underlying TDE print engine supports. Importing files is another issue, but if users realize they can print to PDF perhaps they will demand others do likewise. I have done this professionally too. I use an old version of MS Office and when people send me a docx file I tell them to try again. Guess what? They do. :)
I want to spend several days using all of the KOffice apps in a focused manner to develop a more healthy opinion about what is provided.
Somebody mentioned ODF support. We might need to ensure ODF support is up to date.
Tim, if KOffice ODF support is lagging, can we add that as a candidate for R15 (not R14 --- R15)?
I hope KOffice is not removed from the Trinity line,
but I am wondering how
much work is involved to package the apps separately.
Likely there would
need to be a koffice-base package that contains all
the common libraries,
headers, etc.
hm, there ARE separate packages, e.g. kspread:
aptitude show kspread-trinity
Well, then. Looks like I need to learn how to package the apps separately. Can anybody here help with that? A mini how-to?
Darrel
Something I would like to push more than personal use is office use. Do you think the suite is suitable for office use? (I am not really sure here - I have only played around with it)
On Tuesday 22 November 2011 01:13:50 pm Calvin Morrison wrote:
Something I would like to push more than personal use is office use. Do you think the suite is suitable for office use? (I am not really sure here - I have only played around with it)
From what I remember for a couple years ago, with some slight reworking with the interface and adding some document templates, it should be doable for both personal and professional.
On 22 November 2011 13:29, Kristopher John Gamrat chaotickjg@gmail.comwrote:
On Tuesday 22 November 2011 01:13:50 pm Calvin Morrison wrote:
Something I would like to push more than personal use is office use. Do
you
think the suite is suitable for office use? (I am not really sure here -
I
have only played around with it)
From what I remember for a couple years ago, with some slight reworking with the interface and adding some document templates, it should be doable for both personal and professional.
-- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/
I think it is hard to justify developing an entire suite however, on top of a desktop environment. I'd much rather effort be put towards TDE integration into LOffice, where there is a team of 100+ developers working on it.
I say we leave KOffice how it is, for people who need it, then focus on Loffice (i think this is already the plan?)
Calvin
On Tuesday 22 November 2011 01:31:28 pm Calvin Morrison wrote:
On 22 November 2011 13:29, Kristopher John Gamrat chaotickjg@gmail.comwrote:
On Tuesday 22 November 2011 01:13:50 pm Calvin Morrison wrote:
Something I would like to push more than personal use is office use. Do
you
think the suite is suitable for office use? (I am not really sure here -
I
have only played around with it)
From what I remember for a couple years ago, with some slight reworking with the interface and adding some document templates, it should be doable for both personal and professional.
I think it is hard to justify developing an entire suite however, on top of a desktop environment. I'd much rather effort be put towards TDE integration into LOffice, where there is a team of 100+ developers working on it.
I say we leave KOffice how it is, for people who need it, then focus on Loffice (i think this is already the plan?)
I think we should either bring it up to par with other office suites, or drop it altogether. I'm completely impartial to either. I personally don't use it, but with some improvement I'd definitely try it again.
On 22 November 2011 13:37, Kristopher John Gamrat chaotickjg@gmail.comwrote:
On Tuesday 22 November 2011 01:31:28 pm Calvin Morrison wrote:
On 22 November 2011 13:29, Kristopher John Gamrat <chaotickjg@gmail.com wrote:
On Tuesday 22 November 2011 01:13:50 pm Calvin Morrison wrote:
Something I would like to push more than personal use is office use.
Do
you
think the suite is suitable for office use? (I am not really sure
here -
I
have only played around with it)
From what I remember for a couple years ago, with some slight reworking with the interface and adding some document templates, it should be
doable
for both personal and professional.
I think it is hard to justify developing an entire suite however, on top
of
a desktop environment. I'd much rather effort be put towards TDE integration into LOffice, where there is a team of 100+ developers
working
on it.
I say we leave KOffice how it is, for people who need it, then focus on Loffice (i think this is already the plan?)
I think we should either bring it up to par with other office suites, or drop it altogether. I'm completely impartial to either. I personally don't use it, but with some improvement I'd definitely try it again.
Well there are certain applications like Krita that are not replaceable, and no other programs currently provide their functions.
Anyway, this discussion has already happened a while back.
Calvin
On Tuesday 22 November 2011 01:42:46 pm Calvin Morrison wrote:
On 22 November 2011 13:37, Kristopher John Gamrat chaotickjg@gmail.comwrote:
On Tuesday 22 November 2011 01:31:28 pm Calvin Morrison wrote:
On 22 November 2011 13:29, Kristopher John Gamrat <chaotickjg@gmail.com wrote:
On Tuesday 22 November 2011 01:13:50 pm Calvin Morrison wrote:
Something I would like to push more than personal use is office use.
Do
you
think the suite is suitable for office use? (I am not really sure
here -
I
have only played around with it)
From what I remember for a couple years ago, with some slight reworking with the interface and adding some document templates, it should be
doable
for both personal and professional.
I think it is hard to justify developing an entire suite however, on top
of
a desktop environment. I'd much rather effort be put towards TDE integration into LOffice, where there is a team of 100+ developers
working
on it.
I say we leave KOffice how it is, for people who need it, then focus on Loffice (i think this is already the plan?)
I think we should either bring it up to par with other office suites, or drop it altogether. I'm completely impartial to either. I personally don't use it, but with some improvement I'd definitely try it again.
Well there are certain applications like Krita that are not replaceable, and no other programs currently provide their functions.
There are, but AFAIK they're all GTK.
I can't seem to find a Krita package in Debian Squeeze on 3.5.13, though I know I saw it in 3.5.12.
Anyway, this discussion has already happened a while back.
So why are we still having it? O.o
Well there are certain applications like Krita that are not replaceable, and no other programs currently provide their functions.
Anyway, this discussion has already happened a while back.
Yes, there was a discussion this past summer. The only thing decided was KOffice was not going to be deprecated or abandoned for 3.5.13. Several people noted KOffice provides several apps that have no other TDE replacements. That more or less ended the discussion. That is why I included the full list in my first post starting this thread:
KWord: Word Processing KSpread: Spreadsheets KPresenter: Slide Presentations Karbon14: Scalable Graphics Drawing KPlato: Project Management Kexi: Database Creator Kugar: Database Report Generator KChart: Chart and Graph Creator Kivio: Flowchart and Diagram Editing Chalk: Painting and Image Editing KFormula: Formula Editor
There are arguments for replacing KOffice with OO/LO, or at least stripping KOffice of those apps and repackaging the remainder as individual packages. I'm unconvinced we should rapidly embrace such an approach. As I mentioned, I have not used KWord but I am researching the app and hope to find time to start some serious testing. As a tech writer for almost three decades I think I am qualified to judge KWord. :)
I think we need caution about discarding KOffice. A common statement made by several thus far is few are using the KOffice apps to formulate a qualified option what to do. We need to hear from those who do.
Perhaps several of us can do just that --- test one or two apps in a meaningful manner and provide a report to the team. I mean meaningful testing, not cursory baloney as seen in so many online "reviews."
If you are an experiencd spreadsheet number cruncher person then spend a few days evaluating various aspects of KSpread. If you having drawing talent then evaluate Chalk (a.k.a. Krita) and Karbon14. If you are a local PowerPoint guru then evaluate KPresenter. Somebody should evaluate KPlato. For example, would KPlato help a person with building a home?
Any evaluation should not be how these apps compare to MS Office, but are they palatable for most people for many tasks? Don't look for missing escoteric features. Forget about importing and exporting MS Office files. Focus on usability by typical users with common needs.
I have a feeling KOffice might surprise us all, me included.
With that said, I am not against supporting OO/LO as long as that focus is tight integration with TDE. I hate the OO/LO file picker dialogs. They are useless compared to KDialog. Menu and toolbar look-and-feel needs help. Tim was working on some of that a while ago but I don't what happened. I think Tim told the LO people the TDE team would maintain the hooks needed for TDE integration.
Perhaps after R14 we can have a serious discussion about the future of KOffice. Yet I don't think any such discussion will be valid unless we perform some serious testing and evaluations.
Certainly not an R14 topic of concern but perhaps R15.
Darrell
Any evaluation should not be how these apps compare to MS Office, but are they palatable for most people for many tasks? Don't look for missing escoteric features. Forget about importing and exporting MS Office files. Focus on usability by typical users with common needs.
I think everything you have said was just invalidated by this paragraph. What is a user with common needs? almost 100% of the time that involves MS compat one way or another. It is unrealistic to pretend that users won't need this. And what do we do when they say "oh no I can save my .docx file", do we just say "oh well most common users don't need that?". No.
With that said, I am not against supporting OO/LO as long as that focus is tight integration with TDE. I hate the OO/LO file picker dialogs. They are useless compared to KDialog. Menu and toolbar look-and-feel needs help. Tim was working on some of that a while ago but I don't what happened. I think Tim told the LO people the TDE team would maintain the hooks needed for TDE integration.
This is important obviously, and we don't want to roll out a premature LO picker. I think it is safe to say that OpenOffice is all but dead...
Perhaps after R14 we can have a serious discussion about the future of KOffice. Yet I don't think any such discussion will be valid unless we perform some serious testing and evaluations.
Certainly not an R14 topic of concern but perhaps R15.
Agreed, but we also need to make long term decisions. No point putting weeks of labor into a product just to drop it in a few versions. Make sense?
Calvin Morrison
With that said, I am not against supporting OO/LO as long as that focus is tight integration with TDE. I hate the OO/LO file picker dialogs. They are useless compared to KDialog. Menu and toolbar look-and-feel needs help. Tim was working on some of that a while ago but I don't what happened. I think Tim told the LO people the TDE team would maintain the hooks needed for TDE integration.
<snip>
I knew that all along. ;-) What has thrown me off of that project for a while was the way they wanted it done. Whereas I created a new TDE integration module from the KDE3 sources, they want some kind of hacked-up "frankenmodule" that supports both KDE3 and TDE.
For now I have the patch for the new TDE module (applies against LO GIT) in the TDE GIT tree. I am not exactly sure how to proceed, as I am still convinced maintaining the combined module could be a real nuisance for all parties involved.
Tim
On Tuesday 22 November 2011 03:01:55 pm Timothy Pearson wrote:
With that said, I am not against supporting OO/LO as long as that focus is tight integration with TDE. I hate the OO/LO file picker dialogs. They are useless compared to KDialog. Menu and toolbar look-and-feel needs help. Tim was working on some of that a while ago but I don't what happened. I think Tim told the LO people the TDE team would maintain the hooks needed for TDE integration.
<snip>
I knew that all along. ;-) What has thrown me off of that project for a while was the way they wanted it done. Whereas I created a new TDE integration module from the KDE3 sources, they want some kind of hacked-up "frankenmodule" that supports both KDE3 and TDE.
For now I have the patch for the new TDE module (applies against LO GIT) in the TDE GIT tree. I am not exactly sure how to proceed, as I am still convinced maintaining the combined module could be a real nuisance for all parties involved.
Did they give any reason for continued support for KDE3? I doubt even the distros that continue support for KDE3 would keep it once they find out about TDE, since KDE3 will likely never receive any more updates.
http://nabble.documentfoundation.org/Trinity-Desktop-Environment-TDE-desktop...
Relevant
On 22 November 2011 15:12, Kristopher John Gamrat chaotickjg@gmail.comwrote:
On Tuesday 22 November 2011 03:01:55 pm Timothy Pearson wrote:
With that said, I am not against supporting OO/LO as long as that
focus
is tight integration with TDE. I hate the OO/LO file picker dialogs. They are useless compared to KDialog. Menu and toolbar look-and-feel needs
help.
Tim was working on some of that a while ago but I don't what happened. I think Tim told the LO people the TDE team would maintain the hooks needed
for
TDE integration.
<snip>
I knew that all along. ;-) What has thrown me off of that project for a while was the way they wanted it done. Whereas I created a new TDE integration module from the KDE3 sources, they want some kind of
hacked-up
"frankenmodule" that supports both KDE3 and TDE.
For now I have the patch for the new TDE module (applies against LO GIT) in the TDE GIT tree. I am not exactly sure how to proceed, as I am still convinced maintaining the combined module could be a real nuisance for
all
parties involved.
Did they give any reason for continued support for KDE3? I doubt even the distros that continue support for KDE3 would keep it once they find out about TDE, since KDE3 will likely never receive any more updates.
-- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/
Any evaluation should not be how these apps compare to MS Office, but are they palatable for most people for many tasks? Don't look for missing esoteric features. Forget about importing and exporting MS Office files. Focus on usability by typical users with common needs.
I think everything you have said was just invalidated by this paragraph. What is a user with common needs? almost 100% of the time that involves MS compat one way or another. It is unrealistic to pretend that users won't need this. And what do we do when they say "oh no I can save my .docx file", do we just say "oh well most common users don't need that?". No.
Everything I said was invalidated? Oh Calvin, so melodramatic! :D
I do struggle with the concept of what is a typical or common user. I hesitated before using those terms but did so anyway. :)
First, we are discussing TDE users. That fact distinguishes those users from other users because a TDE user is using a Linux based system and not Windows. Few users of Linux based systems are as naive as the majority of Windows users. :) That is, many Linux based users have a clue about computers.
Second, how much does a TDE user need or care about MS Office compatibility? I don't know the answer. I suspect many don't care. Primarily they are interested in using computers to satisfy their needs and wants, not some brain dead boss's. Thus, any office suite provided with TDE should satisfy the basic office needs of a TDE user and not an enterprise user.
Jeepers creepers, Calvin, just the other day you were screaming to use markup languages for documentation... :D
I don't want to completely ignore compatibility. I am only stressing that our selling point is personal usage, not enterprise usage. I don't know that enterprise support is sustainable for our small team size.
I suspect for simple documents that KOffice will import MS Office documents. I can test that. Yet users need to understand that the more complex the document the more likely importing will be disappointing. We need to provide a little tough love, so to speak. I still have floppy disks from the early 90s of a software package that was nothing more than many dozen file conversion filters. The challenge of file compatibility is nothing new. There never has been a smooth solution and never will. If there was then none of us would support the idea of open formats. :)
We have to sell some realism with usage. Yet if we focus on the positive aspect of personal (and perhaps small office usage) then I think these apps might surprise us all.
Regarding compatibility, professionally I am required to work in Windows, primarily FrameMaker and Word. I have no illusions about using KWord, LO Writer, or (eew!) WINE. I use virtual machines and run those apps natively. I am realistic about what I need to do. KOffice is not for such people. If I did not have those professional requirements I suspect I would be more than happy with LO Writer or KWord.
As I mentioned, with respect to export compatibility, this is a social conditioning challenge. We need to teach people to use the underlying PDF print engine.
We probably do need to look into a docx import filter.
With that said, I am not against supporting OO/LO as long as that focus is tight integration with TDE. I hate the OO/LO file picker dialogs. They are useless compared to KDialog. Menu and toolbar look-and-feel needs help. Tim was working on some of that a while ago but I don't what happened. I think Tim told the LO people the TDE team would maintain the hooks needed for TDE integration.
This is important obviously, and we don't want to roll out a premature LO picker. I think it is safe to say that OpenOffice is all but dead...
I'm including OO just to be nice. We still need an integrated TDE file picker.
Agreed, but we also need to make long term decisions. No point putting weeks of labor into a product just to drop it in a few versions. Make sense?
Makes sense, which is why I recommended some serious evaluations before we get to any discussion point. How can any of us honestly discuss the future of app that none of us use? Even you admitted to not using the apps in any constructive manner. I admitted as much. That excludes both of us from deciding the future of KOffice. I already stated I am willing to help with such evaluations. I understand from a coder's perspective that you might be resistive to supporting a huge code base such as KOffice. Yet if the focus is personal (and perhaps small office usage), then the maintenance perspective changes.
Darrell
On 22 November 2011 15:30, Darrell Anderson humanreadable@yahoo.com wrote:
Any evaluation should not be how these apps compare to MS Office, but are they palatable for most people for many tasks? Don't look for missing esoteric features. Forget about importing and exporting MS Office files. Focus on usability by typical users with common needs.
I think everything you have said was just invalidated by this paragraph. What is a user with common needs? almost 100% of the time that involves MS compat one way or another. It is unrealistic to pretend that users won't need this. And what do we do when they say "oh no I can save my .docx file", do we just say "oh well most common users don't need that?". No.
Everything I said was invalidated? Oh Calvin, so melodramatic! :D
I do struggle with the concept of what is a typical or common user. I hesitated before using those terms but did so anyway. :)
I think we need to figure this out, it comes up quite a lot as a subject.
First, we are discussing TDE users. That fact distinguishes those users from other users because a TDE user is using a Linux based system and not Windows. Few users of Linux based systems are as naive as the majority of Windows users. :) That is, many Linux based users have a clue about computers.
Not necessarily, there are plenty of naive linux users, but still point taken.
Second, how much does a TDE user need or care about MS Office compatibility? I don't know the answer. I suspect many don't care. Primarily they are interested in using computers to satisfy their needs and wants, not some brain dead boss's. Thus, any office suite provided with TDE should satisfy the basic office needs of a TDE user and not an enterprise user.
I do think people care a lot about it! As a student I am required to submit my papers as a microsoft document. Mr Jones, who works in an office is required to turn in a excel sheet of business transaction, he needs MS compatibility. his wife Sue Jones, writes down her cooking recipes to email to her sister-in-law, she needs MS Compatibility. Bobby Jones, their loving son, has to submit power point projects and essays to his high school. He needs MS Compatibility.
Enterprise or not, you need MS Compat any time that you step out of the linux world, so unless the entire network of people around you are using ODT, then you'll need to use DOC.
Jeepers creepers, Calvin, just the other day you were screaming to use markup languages for documentation... :D
I will try and be more reserved. Take everything I say with a grain of salt. I do like you quite a lot Darrell, you are an asset to the team!
I don't want to completely ignore compatibility. I am only stressing that our selling point is personal usage, not enterprise usage. I don't know that enterprise support is sustainable for our small team size.
Already answered above. But I don't think KOffice updates are sustainable for our small size, I would rather opt for LOffice integration and leave KOffice for those who already use it.
Makes sense, which is why I recommended some serious evaluations before we get to any discussion point. How can any of us honestly discuss the future of app that none of us use? Even you admitted to not using the apps in any constructive manner. I admitted as much. That excludes both of us from deciding the future of KOffice. I already stated I am willing to help with such evaluations. I understand from a coder's perspective that you might be resistive to supporting a huge code base such as KOffice. Yet if the focus is personal (and perhaps small office usage), then the maintenance perspective changes.
Well said.
Calvin
I do think people care a lot about it! As a student I am required to submit my papers as a microsoft document. Mr Jones, who works in an office is required to turn in a excel sheet of business transaction, he needs MS compatibility. his wife Sue Jones, writes down her cooking recipes to email to her sister-in-law, she needs MS Compatibility. Bobby Jones, their loving son, has to submit power point projects and essays to his high school. He needs MS Compatibility.
Okay so the Jones family is a hurtin' bunch. :D
Point taken. Let's agree we need reasonable compatibility but let's focus on personal usage rather than enterprise usage.
Enterprise or not, you need MS Compat any time that you step out of the linux world, so unless the entire network of people around you are using ODT, then you'll need to use DOC.
Well, as I said, I am required to maintain full compatibility. I don't fight windmills. I use the required apps natively in a virtual machine. I have no illusions about using non Windows apps to put my beans on the table. :) I think anybody who needs 100% compatibility needs to be realistic.
With that said, often I open MS docs in LO, but only to browse. I don't trust any alleged compatibility claims to acutally change such documents. If I am asked to modify an MS doc then I start my virtual machine.
Jeepers creepers, Calvin, just the other day you were screaming to use markup languages for documentation... :D
I will try and be more reserved. Take everything I say with a grain of salt. I do like you quite a lot Darrell, you are an asset to the team!
Likewise. Wrangling with you young whipper snappers keeps my mind sharper than I might otherwise be. :)
Darrell
On Tuesday 22 November 2011 04:06:53 pm Darrell Anderson wrote:
I do think people care a lot about it! As a student I am required to submit my papers as a microsoft document. Mr Jones, who works in an office is required to turn in a excel sheet of business transaction, he needs MS compatibility. his wife Sue Jones, writes down her cooking recipes to email to her sister-in-law, she needs MS Compatibility. Bobby Jones, their loving son, has to submit power point projects and essays to his high school. He needs MS Compatibility.
Okay so the Jones family is a hurtin' bunch. :D
Point taken. Let's agree we need reasonable compatibility but let's focus on personal usage rather than enterprise usage.
Enterprise or not, you need MS Compat any time that you step out of the linux world, so unless the entire network of people around you are using ODT, then you'll need to use DOC.
Well, as I said, I am required to maintain full compatibility. I don't fight windmills. I use the required apps natively in a virtual machine. I have no illusions about using non Windows apps to put my beans on the table. :) I think anybody who needs 100% compatibility needs to be realistic.
With that said, often I open MS docs in LO, but only to browse. I don't trust any alleged compatibility claims to acutally change such documents. If I am asked to modify an MS doc then I start my virtual machine.
Humans being realistic? That made me laugh! :-)
I don't mean that as an insult. Most people aren't realistic, and they ever will be. I agree with you fully that they need to be realistic, but I know that'll never happen.
I don't think anyone here expects full compatibility, but I think most of us agree that it is important.
Of course, if all their apps work in WINE (and they can afford (and are willing) to renew licenses when needed), or if they were willing to dual boot or use VMs (and they can afford (and are willing) to renew licenses when needed), then KOffice wouldn't need to have compatibility, but that won't be true of everyone.
Humans being realistic? That made me laugh! :-)
I don't mean that as an insult. Most people aren't realistic, and they ever will be. I agree with you fully that they need to be realistic, but I know that'll never happen.
No insult taken! Psychologists and socioligists have shown many times that most humans do not act rationally, despite the claims otherwise.
Darrell
On Tuesday 22 November 2011 03:30:06 pm Darrell Anderson wrote:
Any evaluation should not be how these apps compare to MS Office, but are they palatable for most people for many tasks? Don't look for missing esoteric features. Forget about importing and exporting MS Office files. Focus on usability by typical users with common needs.
I think everything you have said was just invalidated by this paragraph. What is a user with common needs? almost 100% of the time that involves MS compat one way or another. It is unrealistic to pretend that users won't need this. And what do we do when they say "oh no I can save my .docx file", do we just say "oh well most common users don't need that?". No.
Everything I said was invalidated? Oh Calvin, so melodramatic! :D
I do struggle with the concept of what is a typical or common user. I hesitated before using those terms but did so anyway. :)
We need to use the lowest common denominator: They expect to be able to turn on their computer, have it work, and do all their work without having to switch between two or more different programs or operating systems, and they want to have the least wait time, effort, and software to do their work. For example, they won't want to boot to Windows, do all their work, then reboot to Linux, nor do they want to wait for their Linux system to boot, then open a Windows VM and wait for that to boot. Nor will they want to use KOffice, just because they like it, then open it in MS Office to make sure it was formatted correctly.
First, we are discussing TDE users. That fact distinguishes those users from other users because a TDE user is using a Linux based system and not Windows. Few users of Linux based systems are as naive as the majority of Windows users. :) That is, many Linux based users have a clue about computers.
Except the new converts. Even today, I as a Linux user am still somewhat naive, though not nearly as naive as a few years ago when I used Windows exclusively.
Second, how much does a TDE user need or care about MS Office compatibility? I don't know the answer. I suspect many don't care. Primarily they are interested in using computers to satisfy their needs and wants, not some brain dead boss's. Thus, any office suite provided with TDE should satisfy the basic office needs of a TDE user and not an enterprise user.
Even for office use, MS format is often needed.
Jeepers creepers, Calvin, just the other day you were screaming to use markup languages for documentation... :D
I don't want to completely ignore compatibility. I am only stressing that our selling point is personal usage, not enterprise usage. I don't know that enterprise support is sustainable for our small team size.
Perhaps then for personal and normal office use. We don't need to go all the way up to full-fledged enterprise.
I suspect for simple documents that KOffice will import MS Office documents. I can test that. Yet users need to understand that the more complex the document the more likely importing will be disappointing. We need to provide a little tough love, so to speak. I still have floppy disks from the early 90s of a software package that was nothing more than many dozen file conversion filters. The challenge of file compatibility is nothing new. There never has been a smooth solution and never will. If there was then none of us would support the idea of open formats. :)
The hard core FOSS-only people at GNU still would ;-)
The solution I can think of here is to provide a warning box when people open a MS Office document. Tell them that since we do not work with Microsoft or have access to the code, support for their format is not and will never be perfect and may yield unexpected results.
We have to sell some realism with usage. Yet if we focus on the positive aspect of personal (and perhaps small office usage) then I think these apps might surprise us all.
Regarding compatibility, professionally I am required to work in Windows, primarily FrameMaker and Word. I have no illusions about using KWord, LO Writer, or (eew!) WINE. I use virtual machines and run those apps natively. I am realistic about what I need to do. KOffice is not for such people. If I did not have those professional requirements I suspect I would be more than happy with LO Writer or KWord.
WINE is not an illusion for MS Office, I tested this myself with Office 2003 and 2007. While it may not be perfect, it isn't perfect with running them on Windows either. I can't comment on FrameMaker since I've never heard of it.
As I mentioned, with respect to export compatibility, this is a social conditioning challenge. We need to teach people to use the underlying PDF print engine.
We probably do need to look into a docx import filter.
With that said, I am not against supporting OO/LO as long as that focus is tight integration with TDE. I hate the OO/LO file picker dialogs. They are useless compared to KDialog. Menu and toolbar look-and-feel needs help. Tim was working on some of that a while ago but I don't what happened. I think Tim told the LO people the TDE team would maintain the hooks needed for TDE integration.
This is important obviously, and we don't want to roll out a premature LO picker. I think it is safe to say that OpenOffice is all but dead...
I'm including OO just to be nice. We still need an integrated TDE file picker.
Agreed, but we also need to make long term decisions. No point putting weeks of labor into a product just to drop it in a few versions. Make sense?
Makes sense, which is why I recommended some serious evaluations before we get to any discussion point. How can any of us honestly discuss the future of app that none of us use? Even you admitted to not using the apps in any constructive manner. I admitted as much. That excludes both of us from deciding the future of KOffice. I already stated I am willing to help with such evaluations. I understand from a coder's perspective that you might be resistive to supporting a huge code base such as KOffice. Yet if the focus is personal (and perhaps small office usage), then the maintenance perspective changes.
Better integration with LO is a good idea, but only because not everybody will like KOffice, even if we do continue it :-)
MS Office compatibility is not the most important aspect of continuing to include KOffice, but should certainly be included. The whole reason I've always used OOo/LO instead of KOffice is because of school -- I occaisionally need to use MS Office format for assignments, and LO just has better support. I'll never expect support to be perfect, but there are other users who will want it, whether for education, job, or sharing documents with friends. A lot of Windows and Mac users will use TDE when they switch to Linux, and they'll be coming from a world where MS Office is the dominant format. Yes, they can use VMs and dual booting, but what if they can't afford the licensing or they don't want a VM or a dual boot? That leaves them with WINE, but if MS Office is the only thing they use it for, they might not want it. I've even talked to a few people over the last few years that have said that since they're switching to FOSS, they want to just take the plunge and go all the way (as in, use only FOSS, and eliminate the proprietary stuff, including Flash and Java), yet they need MS Office format for work.
The most important aspects of keepingg KOffice is usability, stability, and support for recent ODF specs. MS Office support is secondary.
First, we are discussing TDE users. That fact
distinguishes those users from other users because a TDE user is using a Linux based system and not Windows. Few users of Linux based systems are as naive as the majority of Windows users. :) That is, many Linux based users have a clue about computers.
Except the new converts. Even today, I as a Linux user am still somewhat naive, though not nearly as naive as a few years ago when I used Windows exclusively.
My use of the word naive was a poor choice. I think the point I wanted to make is Linux based users tend to be less intimidated by computers than Windows users. Just a couple of months I ago I conducted a training class and one of the attendees uttered, "You can do that?" when I demonstrated a particular method of performing the computer task we were discussing. I know all of the people in that class. All of them are smart and sharp. None of them are computer people. If nobody shows them how to work more efficiently on a computer with certain tasks they never learn.
I have watched people type information into dialog boxes. Instead of using the Tab key to keep their hands on the keyboard, they type into one text box, stop, grab the mouse, click into the next text box, type, stop, etc. These people don't "grok" computers at all. People who adopt Linux based systems are more likely to explore and ask questions. I think that was my point.
Until the day arrives, if ever, when Linux based systems with TDE are preinstalled, then I think we keep dealing with that type of user.
I suspect for simple documents that KOffice will
import MS Office documents. I can test that. Yet users need to understand that the more complex the document the more likely importing will be disappointing. We need to provide a little tough love, so to speak. I still have floppy disks from the early 90s of a software package that was nothing more than many dozen file conversion filters. The challenge of file compatibility is nothing new. There never has been a smooth solution and never will. If there was then none of us would support the idea of open formats. :)
The hard core FOSS-only people at GNU still would ;-)
I probably would too. I remember the 1980s and 1990s when there were many more apps on the market than just MS software. File conversions were a nightmare and a profitable business, even moreso than today. Even way back then I wanted common file formats.
The solution I can think of here is to provide a warning box when people open a MS Office document. Tell them that since we do not work with Microsoft or have access to the code, support for their format is not and will never be perfect and may yield unexpected results.
I like that idea. If we provide such a dialog box then be sure to include a check box "Don't show this message again."
WINE is not an illusion for MS Office, I tested this myself with Office 2003 and 2007. While it may not be perfect, it isn't perfect with running them on Windows either. I can't comment on FrameMaker since I've never heard of it.
I have tried WINE, although a few years ago. Not worth the stress. Additionally, there is no official support in WINE for macros. Several of my templates depend heavily on macros and that was the end of my testing right there.
I was very happy when VirtualBox became available. I bought new hardware and have been happy with running Windows that way. I accept that not everybody wants to do that or has the hardware to handle that kind of load.
I am one of the few people who rarely experience MS apps crashing. I've heard the complaints for years but that has not been my experience. Likewise with BSODs. I never saw that many. Then again, I've been around computers a long time. Perhaps I was configuring my systems in a manner that avoided those problems. I also tend to be a single tasker and don't run two dozens different apps at one time.
FrameMaker is a de facto standard app in the tech writing world. FrameMaker actually started on Unix systems back in the late 80s. Only after Adobe bought the software in the 90s did Unix support end. There was a brief fling a few years back from the Adobe people with a beta version for Linux based systems, but never went to market. Too bad. Because of my professional dependence, I more than likely would have purchased a copy. Expensive vertical market software too.
Darrell
On Tuesday 22 November 2011 02:34:31 pm Darrell Anderson wrote:
Well there are certain applications like Krita that are not replaceable, and no other programs currently provide their functions.
Anyway, this discussion has already happened a while back.
Yes, there was a discussion this past summer. The only thing decided was KOffice was not going to be deprecated or abandoned for 3.5.13. Several people noted KOffice provides several apps that have no other TDE replacements. That more or less ended the discussion. That is why I included the full list in my first post starting this thread:
KWord: Word Processing KSpread: Spreadsheets KPresenter: Slide Presentations Karbon14: Scalable Graphics Drawing KPlato: Project Management Kexi: Database Creator Kugar: Database Report Generator KChart: Chart and Graph Creator Kivio: Flowchart and Diagram Editing Chalk: Painting and Image Editing KFormula: Formula Editor
There are arguments for replacing KOffice with OO/LO, or at least stripping KOffice of those apps and repackaging the remainder as individual packages. I'm unconvinced we should rapidly embrace such an approach. As I mentioned, I have not used KWord but I am researching the app and hope to find time to start some serious testing. As a tech writer for almost three decades I think I am qualified to judge KWord. :)
I think we need caution about discarding KOffice. A common statement made by several thus far is few are using the KOffice apps to formulate a qualified option what to do. We need to hear from those who do.
Perhaps several of us can do just that --- test one or two apps in a meaningful manner and provide a report to the team. I mean meaningful testing, not cursory baloney as seen in so many online "reviews."
If you are an experiencd spreadsheet number cruncher person then spend a few days evaluating various aspects of KSpread. If you having drawing talent then evaluate Chalk (a.k.a. Krita) and Karbon14. If you are a local PowerPoint guru then evaluate KPresenter. Somebody should evaluate KPlato. For example, would KPlato help a person with building a home?
Any evaluation should not be how these apps compare to MS Office, but are they palatable for most people for many tasks? Don't look for missing escoteric features. Forget about importing and exporting MS Office files. Focus on usability by typical users with common needs.
I have a feeling KOffice might surprise us all, me included.
With that said, I am not against supporting OO/LO as long as that focus is tight integration with TDE. I hate the OO/LO file picker dialogs. They are useless compared to KDialog. Menu and toolbar look-and-feel needs help. Tim was working on some of that a while ago but I don't what happened. I think Tim told the LO people the TDE team would maintain the hooks needed for TDE integration.
Perhaps after R14 we can have a serious discussion about the future of KOffice. Yet I don't think any such discussion will be valid unless we perform some serious testing and evaluations.
Certainly not an R14 topic of concern but perhaps R15.
Unfortunately having at least basic support for MS Office documents should be considered. As I said, I don't think it should be a main concern, but certainly considered in the future. There are people, myself included, who cannot afford MS software, yet many of us require support for MS Office format for our jobs and/or education, but can't always stay at work or school long enough to finish these. Sure, it's easy to convert to RTF for home use, but what if the boss expects it to be emailed using MS Office format? Just something to consider.
I just installed and opened KOffice. I like the menu idea (as in, the templates menu that shows when a KOffice app is opened). I definitely think this idea should be discussed as far as improvements are concerned, and that more templates should be included.
I haven't yet confirmed the ODF issue, but that definitely needs looked at to see if it needs updating.
I will definitely spend more time in KOffice. Even if it does use an old version of ODF, I'm sure OOo/LO will still open it. I'll see if I can come up with more pros and cons for KOffice.
On Tuesday 22 November 2011 19:31:28 Calvin Morrison wrote:
I say we leave KOffice how it is, for people who need it, then focus on Loffice (i think this is already the plan?)
I'm ok with that, trying to bring koffice to par with office suites depeloped by huge teams is pointless. but _please_ leave it just as-is in TDE as long as there is not a viable, lightweight alternative. I remember a discussion awhile ago on trinity-users (?) where koffice2 was mentioned, which would eventually be based on qt4 only (_not_ kde4). maybe there's a chance to have something like that in awhile ?
werner p.s.: the existence of koffice 1.6.3 was one important argument for me to use TDE :) I know support for M$ formats in koffice (1.6) is bad, but recent versions can read the odf files that koffice produces, as does OO/LO, and google docs. that is enough 'compatibility' for me.
On Wednesday 23 November 2011 11:07:14 am Werner Joss wrote:
On Tuesday 22 November 2011 19:31:28 Calvin Morrison wrote:
I say we leave KOffice how it is, for people who need it, then focus on Loffice (i think this is already the plan?)
I'm ok with that, trying to bring koffice to par with office suites depeloped by huge teams is pointless. but _please_ leave it just as-is in TDE as long as there is not a viable, lightweight alternative. I remember a discussion awhile ago on trinity-users (?) where koffice2 was mentioned, which would eventually be based on qt4 only (_not_ kde4). maybe there's a chance to have something like that in awhile ?
Once it is up-to-par, we probably won't need to touch it for a long while, except to update ODF (and possibly MS Office) support. We don't need to add in every feature under the sun, being lightweight saves us from doing that. But perhaps at least add in a plugins feature for people who like KOffice but need more features?
werner p.s.: the existence of koffice 1.6.3 was one important argument for me to use TDE :) I know support for M$ formats in koffice (1.6) is bad, but recent versions can read the odf files that koffice produces, as does OO/LO, and google docs. that is enough 'compatibility' for me.
I think for /most/ Linux users, ODF is the most important to support, though as has already been said, some people just need it. Again, I think it should be a secondary concern (not a main concern), but still needed.
I say we leave KOffice how it is, for people who need
it, then focus on
Loffice (i think this is already the plan?)
I'm ok with that, trying to bring koffice to par with office suites depeloped by huge teams is pointless. but _please_ leave it just as-is in TDE as long as there is not a viable, lightweight alternative. I remember a discussion awhile ago on trinity-users (?) where koffice2 was mentioned, which would eventually be based on qt4 only (_not_ kde4). maybe there's a chance to have something like that in awhile ?
werner p.s.: the existence of koffice 1.6.3 was one important argument for me to use TDE :) I know support for M$ formats in koffice (1.6) is bad, but recent versions can read the odf files that koffice produces, as does OO/LO, and google docs. that is enough 'compatibility' for me.
I agree we are unlikely to massage KO to compete with LO. I'm fine with the idea of keeping KO as a light weight office suite --- and we advertise the apps as such. If we do that we should regularly fix usability bugs (ignore all but easy enhancement requests). If we go that route, then I think we should split the monster-sized package into individual packages in the source tree. That way people can pick and choose.
I don't think we will find a consensus opinion about how to handle KO. Maintaining "as is" with reasonable bug fixes and letting people pick which apps they want to install is probably the best compromise. :)
Darrell
On Wednesday 23 November 2011 11:19:05 am Darrell Anderson wrote:
I say we leave KOffice how it is, for people who need
it, then focus on
Loffice (i think this is already the plan?)
I'm ok with that, trying to bring koffice to par with office suites depeloped by huge teams is pointless. but _please_ leave it just as-is in TDE as long as there is not a viable, lightweight alternative. I remember a discussion awhile ago on trinity-users (?) where koffice2 was mentioned, which would eventually be based on qt4 only (_not_ kde4). maybe there's a chance to have something like that in awhile ?
werner p.s.: the existence of koffice 1.6.3 was one important argument for me to use TDE :) I know support for M$ formats in koffice (1.6) is bad, but recent versions can read the odf files that koffice produces, as does OO/LO, and google docs. that is enough 'compatibility' for me.
I agree we are unlikely to massage KO to compete with LO. I'm fine with the idea of keeping KO as a light weight office suite --- and we advertise the apps as such. If we do that we should regularly fix usability bugs (ignore all but easy enhancement requests). If we go that route, then I think we should split the monster-sized package into individual packages in the source tree. That way people can pick and choose.
I don't think we will find a consensus opinion about how to handle KO. Maintaining "as is" with reasonable bug fixes and letting people pick which apps they want to install is probably the best compromise. :)
I doubt we would ever compete with LO unless we separate KOffice from TDE completely.
I think the only "feature" we should add is a plugins system for users to be able to develop their own features. Other than that, I agree with doing only bug fixes.
On 23 November 2011 11:26, Kristopher John Gamrat chaotickjg@gmail.comwrote:
On Wednesday 23 November 2011 11:19:05 am Darrell Anderson wrote:
I say we leave KOffice how it is, for people who need
it, then focus on
Loffice (i think this is already the plan?)
I'm ok with that, trying to bring koffice to par with office suites depeloped by huge teams is pointless. but _please_ leave it just as-is in TDE as long as there is not a viable, lightweight alternative. I remember a discussion awhile ago on trinity-users (?) where koffice2 was mentioned, which would eventually be based on qt4 only (_not_ kde4). maybe there's a chance to have something like that in awhile ?
werner p.s.: the existence of koffice 1.6.3 was one important argument for me to use TDE :) I know support for M$ formats in koffice (1.6) is bad, but recent versions can read the odf files that koffice produces, as does OO/LO, and google docs. that is enough 'compatibility' for me.
I agree we are unlikely to massage KO to compete with LO. I'm fine with
the idea of keeping KO as a light weight office suite --- and we advertise the apps as such. If we do that we should regularly fix usability bugs (ignore all but easy enhancement requests). If we go that route, then I think we should split the monster-sized package into individual packages in the source tree. That way people can pick and choose.
I don't think we will find a consensus opinion about how to handle KO.
Maintaining "as is" with reasonable bug fixes and letting people pick which apps they want to install is probably the best compromise. :)
I doubt we would ever compete with LO unless we separate KOffice from TDE completely.
I think the only "feature" we should add is a plugins system for users to be able to develop their own features. Other than that, I agree with doing only bug fixes.
-- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/
There is an old saying that is used quite frequently in the archlinux development list.
"Patches Welcome"
So if anyone wants to update koffice, patch koffice, implement a plugin system for koffice. Go ahead! I am sure we will accept patches. But "deciding" what to do on the mailing list, then leaving the work to Timothy doesn't seem fair to me.
My two cents.
Calvin Morrison
On Wednesday 23 November 2011 11:36:55 am Calvin Morrison wrote:
On 23 November 2011 11:26, Kristopher John Gamrat chaotickjg@gmail.comwrote:
On Wednesday 23 November 2011 11:19:05 am Darrell Anderson wrote:
I say we leave KOffice how it is, for people who need
it, then focus on
Loffice (i think this is already the plan?)
I'm ok with that, trying to bring koffice to par with office suites depeloped by huge teams is pointless. but _please_ leave it just as-is in TDE as long as there is not a viable, lightweight alternative. I remember a discussion awhile ago on trinity-users (?) where koffice2 was mentioned, which would eventually be based on qt4 only (_not_ kde4). maybe there's a chance to have something like that in awhile ?
werner p.s.: the existence of koffice 1.6.3 was one important argument for me to use TDE :) I know support for M$ formats in koffice (1.6) is bad, but recent versions can read the odf files that koffice produces, as does OO/LO, and google docs. that is enough 'compatibility' for me.
I agree we are unlikely to massage KO to compete with LO. I'm fine with
the idea of keeping KO as a light weight office suite --- and we advertise the apps as such. If we do that we should regularly fix usability bugs (ignore all but easy enhancement requests). If we go that route, then I think we should split the monster-sized package into individual packages in the source tree. That way people can pick and choose.
I don't think we will find a consensus opinion about how to handle KO.
Maintaining "as is" with reasonable bug fixes and letting people pick which apps they want to install is probably the best compromise. :)
I doubt we would ever compete with LO unless we separate KOffice from TDE completely.
I think the only "feature" we should add is a plugins system for users to be able to develop their own features. Other than that, I agree with doing only bug fixes.
-- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/
There is an old saying that is used quite frequently in the archlinux development list.
"Patches Welcome"
So if anyone wants to update koffice, patch koffice, implement a plugin system for koffice. Go ahead! I am sure we will accept patches. But "deciding" what to do on the mailing list, then leaving the work to Timothy doesn't seem fair to me.
Nobody said we wouldn't help. I'd have already been submitting patches if I knew how to code.
On 23 November 2011 11:42, Kristopher John Gamrat chaotickjg@gmail.comwrote:
On Wednesday 23 November 2011 11:36:55 am Calvin Morrison wrote:
On 23 November 2011 11:26, Kristopher John Gamrat <chaotickjg@gmail.com wrote:
On Wednesday 23 November 2011 11:19:05 am Darrell Anderson wrote:
I say we leave KOffice how it is, for people who need
it, then focus on
Loffice (i think this is already the plan?)
I'm ok with that, trying to bring koffice to par with office suites depeloped by huge teams is pointless. but _please_ leave it just as-is in TDE as long as there is not a viable, lightweight alternative. I remember a discussion awhile ago on trinity-users (?) where koffice2 was mentioned, which would eventually be based on qt4 only (_not_ kde4). maybe there's a chance to have something like that in awhile ?
werner p.s.: the existence of koffice 1.6.3 was one important argument for me to use TDE :) I know support for M$ formats in koffice (1.6) is bad, but recent versions can read the odf files that koffice produces, as does OO/LO, and google docs. that is enough 'compatibility' for me.
I agree we are unlikely to massage KO to compete with LO. I'm fine
with
the idea of keeping KO as a light weight office suite --- and we
advertise
the apps as such. If we do that we should regularly fix usability bugs (ignore all but easy enhancement requests). If we go that route, then I think we should split the monster-sized package into individual
packages in
the source tree. That way people can pick and choose.
I don't think we will find a consensus opinion about how to handle
KO.
Maintaining "as is" with reasonable bug fixes and letting people pick
which
apps they want to install is probably the best compromise. :)
I doubt we would ever compete with LO unless we separate KOffice from
TDE
completely.
I think the only "feature" we should add is a plugins system for users
to
be able to develop their own features. Other than that, I agree with
doing
only bug fixes.
-- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/
There is an old saying that is used quite frequently in the archlinux development list.
"Patches Welcome"
So if anyone wants to update koffice, patch koffice, implement a plugin system for koffice. Go ahead! I am sure we will accept patches. But "deciding" what to do on the mailing list, then leaving the work to
Timothy
doesn't seem fair to me.
Nobody said we wouldn't help. I'd have already been submitting patches if I knew how to code.
Then now is the time to learn :)
We need developers and the more the better.
Calvin
On Wednesday 23 November 2011 11:45:12 am Calvin Morrison wrote:
On 23 November 2011 11:42, Kristopher John Gamrat chaotickjg@gmail.comwrote:
On Wednesday 23 November 2011 11:36:55 am Calvin Morrison wrote:
On 23 November 2011 11:26, Kristopher John Gamrat <chaotickjg@gmail.com wrote:
On Wednesday 23 November 2011 11:19:05 am Darrell Anderson wrote:
> I say we leave KOffice how it is, for people who need it, then focus on > Loffice (i think this is already the plan?)
I'm ok with that, trying to bring koffice to par with office suites depeloped by huge teams is pointless. but _please_ leave it just as-is in TDE as long as there is not a viable, lightweight alternative. I remember a discussion awhile ago on trinity-users (?) where koffice2 was mentioned, which would eventually be based on qt4 only (_not_ kde4). maybe there's a chance to have something like that in awhile ?
werner p.s.: the existence of koffice 1.6.3 was one important argument for me to use TDE :) I know support for M$ formats in koffice (1.6) is bad, but recent versions can read the odf files that koffice produces, as does OO/LO, and google docs. that is enough 'compatibility' for me.
I agree we are unlikely to massage KO to compete with LO. I'm fine
with
the idea of keeping KO as a light weight office suite --- and we
advertise
the apps as such. If we do that we should regularly fix usability bugs (ignore all but easy enhancement requests). If we go that route, then I think we should split the monster-sized package into individual
packages in
the source tree. That way people can pick and choose.
I don't think we will find a consensus opinion about how to handle
KO.
Maintaining "as is" with reasonable bug fixes and letting people pick
which
apps they want to install is probably the best compromise. :)
I doubt we would ever compete with LO unless we separate KOffice from
TDE
completely.
I think the only "feature" we should add is a plugins system for users
to
be able to develop their own features. Other than that, I agree with
doing
only bug fixes.
-- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/
There is an old saying that is used quite frequently in the archlinux development list.
"Patches Welcome"
So if anyone wants to update koffice, patch koffice, implement a plugin system for koffice. Go ahead! I am sure we will accept patches. But "deciding" what to do on the mailing list, then leaving the work to
Timothy
doesn't seem fair to me.
Nobody said we wouldn't help. I'd have already been submitting patches if I knew how to code.
Then now is the time to learn :)
We need developers and the more the better.
Calvin
If you can provide me with an instant college education and a career that won't take up too much of my time, then sure. Otherwise, it will take me a loooooooooooooooooooooooooong time to get started and eventually get to the point of contributing any code.
Nobody said we wouldn't help. I'd have already been submitting patches if I knew how to code.
I never got the impression anybody was implying we all dump on Tim. :) I think all statements on this list suggesting improvements, possible road maps, etc., all imply team involvement.
From what I see on the list and watching the bug list, many people are indeed helping. Not all patches are C++ hacks, but when people can they have been submitting patches to config files, desktop files, graphics, etc. Many who don't code are involved with testing. Based on the discussions we have had about quality assurance, we need those people too. :)
Then now is the time to learn :) We need developers and the more the better.
I would like to learn. I have a sufficient programming background that I should be able to learn C++. I would love to help in a small way. I need a decent tutorial, one that is specific to this project, how to bootstrap myself. Yes, I need to read a few generic C++ tutorials, but how do I use KDevelop? How do I create a working environment? Would be nice to sit with somebody for a few hours to learn in a rapid manner. People who do this every day tend to forget that even the basic tasks like setting up an IDE is daunting without help. Sure, an experienced coder can work with only a text editor, but not the newbie. An IDE helps validate code, syntax, etc.
IDEs, classes, namespaces.... Where to begin? :)
Darrell
On Wednesday 23 November 2011 12:13:32 pm Darrell Anderson wrote:
Nobody said we wouldn't help. I'd have already been submitting patches if I knew how to code.
I never got the impression anybody was implying we all dump on Tim. :) I think all statements on this list suggesting improvements, possible road maps, etc., all imply team involvement.
From what I see on the list and watching the bug list, many people are indeed helping. Not all patches are C++ hacks, but when people can they have been submitting patches to config files, desktop files, graphics, etc. Many who don't code are involved with testing. Based on the discussions we have had about quality assurance, we need those people too. :)
Then now is the time to learn :) We need developers and the more the better.
I would like to learn. I have a sufficient programming background that I should be able to learn C++. I would love to help in a small way. I need a decent tutorial, one that is specific to this project, how to bootstrap myself. Yes, I need to read a few generic C++ tutorials, but how do I use KDevelop? How do I create a working environment? Would be nice to sit with somebody for a few hours to learn in a rapid manner. People who do this every day tend to forget that even the basic tasks like setting up an IDE is daunting without help. Sure, an experienced coder can work with only a text editor, but not the newbie. An IDE helps validate code, syntax, etc.
IDEs, classes, namespaces.... Where to begin? :)
I already know of a few IDEs, but every time I open one I get scared and click the big X in the upper right corner of the screen ;-)
If I didn't have a teacher to guide me through Visual Basic in high school, I'd have done the same thing.
If I didn't have a teacher in Java class, I'd have done the same thing.
Now the part my my brain that held all my programming knowledge has rotted away, so we definitely need a guide. I think having an experienced programmer create some TDE-sepcific docs (with links to some general resources), and some people who are willing to walk people through on IRC or instant messaging. Any volunteers?
On Wednesday 23 November 2011 18:13:32 Darrell Anderson wrote:
IDEs, classes, namespaces.... Where to begin? :)
there are still tutorials for kde3 development at http://techbase.kde.org/Development/Tutorials/KDE3 - they do not cover kdevelop, though.
werner
On Wednesday 23 November 2011 12:34:26 pm Werner Joss wrote:
On Wednesday 23 November 2011 18:13:32 Darrell Anderson wrote:
IDEs, classes, namespaces.... Where to begin? :)
there are still tutorials for kde3 development at http://techbase.kde.org/Development/Tutorials/KDE3
- they do not cover kdevelop, though.
I'm sure that would work for the most part, but would need to be rewritten with TQt in mind.
On Wednesday 23 November 2011 18:34:58 Kristopher John Gamrat wrote:
On Wednesday 23 November 2011 12:34:26 pm Werner Joss wrote:
On Wednesday 23 November 2011 18:13:32 Darrell Anderson wrote:
IDEs, classes, namespaces.... Where to begin? :)
there are still tutorials for kde3 development at http://techbase.kde.org/Development/Tutorials/KDE3
- they do not cover kdevelop, though.
I'm sure that would work for the most part, but would need to be rewritten with TQt in mind.
I'm pretty sure that everything with regard to coding itself still holds, what will be effected by the tqt interface is the makefile/autoconf stuff. as well as the cmake transition, which is not covered at all by the mentioned tutorials (and also not supported by kdevelop3, IMHO).
werner
Le Wed, 23 Nov 2011 18:58:07 +0100, Werner Joss werner@hoernerfranzracing.de a écrit :
I'm pretty sure that everything with regard to coding itself still holds, what will be effected by the tqt interface is the makefile/autoconf stuff. as well as the cmake transition, which is not covered at all by the mentioned tutorials (and also not supported by kdevelop3, IMHO).
I agree. You can look at $PREFIX/include/tqt/tqt.h, it is 95% of #define's only translating TQ* namespace to Q* namespace and 5% of strange static_cast's.
werner
On Wednesday 23 November 2011 18:34:26 Werner Joss wrote:
there are still tutorials for kde3 development at http://techbase.kde.org/Development/Tutorials/KDE3
- they do not cover kdevelop, though.
maybe it is also a good idea to archive these somewhere on the TDE webspace, as they are marked for deletion at the original site.
werner
there are still tutorials for kde3 development at http://techbase.kde.org/Development/Tutorials/KDE3
- they do not cover kdevelop, though.
maybe it is also a good idea to archive these somewhere on the TDE webspace, as they are marked for deletion at the original site.
How do we do that? Recursive wget?
Does the original KDE3 web site exist anywhere? Cached/archived? Wayback? There is a lot of material we might be able to use.
Darrell
On Wednesday 23 November 2011 20:00:03 Darrell Anderson wrote:
How do we do that? Recursive wget?
probably, yes.
Does the original KDE3 web site exist anywhere? Cached/archived? Wayback? There is a lot of material we might be able to use.
the original site doesn't exist anymore, IMHO. wayback machine could help, maybe.
werner
Le 23/11/2011 20:00, Darrell Anderson a écrit :
there are still tutorials for kde3 development at http://techbase.kde.org/Development/Tutorials/KDE3
- they do not cover kdevelop, though.
maybe it is also a good idea to archive these somewhere on the TDE webspace, as they are marked for deletion at the original site.
How do we do that? Recursive wget?
I downloaded a lot of things with this script:
------------------------------------- #!/bin/bash ADRESSES=" http://techbase.kde.org/Development/Tutorials/KNewStuffSecure/ http://techbase.kde.org/Development/Tutorials/Introduction_to_Get_Hot_New_St... http://techbase.kde.org/Development/Tutorials/KDE3/ http://techbase.kde.org/Development/Architecture/KDE3/ http://techbase.kde.org/Getting_Started/Build/Historic/KDE_3.5/ http://techbase.kde.org/Development/Architecture/DCOP/ " DIR=techbase-kde3 OPTIONS="-r --force-directories --execute robots=off --timestamping \ --page-requisites --convert-links --backup-converted \ -P $DIR -a $DIR/$DIR.log --wait=6 --random-wait --user-agent=firefox" mkdir -v $DIR touch $DIR/$DIR.log for x in $ADRESSES ; do wget $OPTIONS --no-parent $x # wget $OPTIONS --level=2 $x # too much things done -------------------------------------
There is also useful tarballs here: http://api.kde.org/3.5-api/
Does the original KDE3 web site exist anywhere? Cached/archived? Wayback? There is a lot of material we might be able to use.
I downloaded some pages about kio slaves from wayback with:
------------------------------------- #!/bin/bash
DIR=kioslaves URL=http://web.archive.org/web/20081222233709/http://developer.kde.org/documenta... OPTIONS="-r --force-directories --execute robots=off --timestamping \ --page-requisites --convert-links --backup-converted \ -P $DIR -a $DIR/$DIR.log --wait=6 --random-wait --user-agent=firefox" mkdir -v $DIR touch $DIR/$DIR.log wget $OPTIONS --level=2 --no-parent $URL -------------------------------------
Hope it helps.
Le Wed, 23 Nov 2011 09:13:32 -0800 (PST), Darrell Anderson humanreadable@yahoo.com a écrit :
Nobody said we wouldn't help. I'd have already been submitting patches if I knew how to code.
I never got the impression anybody was implying we all dump on Tim. :) I think all statements on this list suggesting improvements, possible road maps, etc., all imply team involvement.
From what I see on the list and watching the bug list, many people are indeed helping. Not all patches are C++ hacks, but when people can they have been submitting patches to config files, desktop files, graphics, etc. Many who don't code are involved with testing. Based on the discussions we have had about quality assurance, we need those people too. :)
Then now is the time to learn :) We need developers and the more the better.
I would like to learn. I have a sufficient programming background that I should be able to learn C++. I would love to help in a small way. I need a decent tutorial, one that is specific to this project, how to bootstrap myself. Yes, I need to read a few generic C++ tutorials, but how do I use KDevelop? How do I create a working environment? Would be nice to sit with somebody for a few hours to learn in a rapid manner. People who do this every day tend to forget that even the basic tasks like setting up an IDE is daunting without help. Sure, an experienced coder can work with only a text editor, but not the newbie. An IDE helps validate code, syntax, etc.
IDEs, classes, namespaces.... Where to begin? :)
I would answer: with standard C++. You won't have to know every detail of C++ (actually I don't think many people do, except Bjarne Stroustrup). Especially STL won't be useful for you since Qt3/Qt4/TQt has its own standard templates (QList, QString, etc. while STL containers are std::list, std::string, etc.). I don't know much about Qt3/KDE3 API but the few times I used the Qt3 documentation (directly from the Nokia website) I found it really good. About IDE's, you don't really need a full-blown IDE like Code::Blocks or KDevelop to validate syntax; Kate, vim and Emacs also have syntax colouring and bracket matching. Anyway the only real check against bad code is compiling and testing ;). For class/function searching, I actually use find/grep but Emacs and vim support ctags which makes jumping through functions much quicker. If you think KDevelop is better for you, feel free to use it but I'm not sure at all whether KDE3 KDevelop supports cmake-based source code. KDE4 KDevelop does. With KDE4 KDevelop I'm able to open the kdebase 3.5.13 CMakeLists.txt, and it loads automatically the full source code. However, I didn't find how to change the include path, so TQt calls are either not found or attributed to Qt4.
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Wednesday 23 November 2011 21:22:24 /dev/ammo42 wrote:
About IDE's, you don't really need a full-blown IDE like Code::Blocks or KDevelop to validate syntax; Kate, vim and Emacs also have syntax colouring and bracket matching. Anyway the only real check against bad code is compiling and testing ;). For class/function searching, I actually use find/grep but Emacs and vim support ctags which makes jumping through functions much quicker. If you think KDevelop is better for you, feel free to use it but I'm not sure at all whether KDE3 KDevelop supports cmake-based source code. KDE4 KDevelop does. With KDE4 KDevelop I'm able to open the kdebase 3.5.13 CMakeLists.txt, and it loads automatically the full source code. However, I didn't find how to change the include path, so TQt calls are either not found or attributed to Qt4.
Curently I use QT Creator for developing TDE stuff. Is really a good IDE.
On Tuesday 22 November 2011 12:06:51 pm Darrell Anderson wrote:
If this suite is advertised as a personal office suite
rather than
professional the apps remain viable for many Trinity
users. The tight
integration with TDE is a bonus too.
absolutely, yes. I like kword and kspread well, ligthtweight, fast, well integrated, does (nearly) every thing I need, so far. some quirks though (inconsistent font sizes, e.g.). (I also tried koffice2.x several times, before it became calligra, and it was a complete mess, unusable, data loss etc.). OO, however, is a monster and just plain overkill, I just use it rarely when I have to look at some M$-office documents sent from someone...
I think our approach must not focus on MS compatibility. That is a hill far too steep to climb. Not even the OO/LO people have achieved that --- and they never will. Every time I test importing complex Word documents into OO/LO Writer they look broken. I'm talking complex documents, not simple letters and memos with manual formatting. :) I have no hope of any free/libre word processor having full compatibility with MS Office --- nor do I care. The TDE team should focus "marketing" efforts on KOffice as a personal office suite. Ignore the compatibility discussions.
Of course full compatibility won't ever be achieved. However, even OOo/Lo do it better than KOffice. I don't want to suggest making it a main concern, though I do think we should make a future goal to at least "catch up" with OOo/LO.
Somebody mentioned ODF support. We might need to ensure ODF support is up to date.
Tim, if KOffice ODF support is lagging, can we add that as a candidate for R15 (not R14 --- R15)?
It was awhile back when I used KOffice. I haven't used it since 3.5.9, I don't know if it was updated in 3.5.10, though it would probably still need updated.
I hope KOffice is not removed from the Trinity line,
but I am wondering how
much work is involved to package the apps separately.
Likely there would
need to be a koffice-base package that contains all
the common libraries,
headers, etc.
hm, there ARE separate packages, e.g. kspread:
aptitude show kspread-trinity
Well, then. Looks like I need to learn how to package the apps separately. Can anybody here help with that? A mini how-to?
You'd need to separate the files into different packages. Put the core libraries in one package, then separate the binaries and other libraries into other packages. If you use RPM for package management, I can provide an example of how to do that. I don't know how to do packaging on any other system.
Well, then. Looks like I need to learn how to package
the apps separately. Can anybody here help with that? A mini how-to?
You'd need to separate the files into different packages. Put the core libraries in one package, then separate the binaries and other libraries into other packages. If you use RPM for package management, I can provide an example of how to do that. I don't know how to do packaging on any other system.
I don't use RPM, but I can uncompress rpms. As long as the build scripts are inside the rpm I probably can convert the build scripts to Slackware.
Darrell
On Tuesday 22 November 2011 04:23:35 pm Darrell Anderson wrote:
Well, then. Looks like I need to learn how to package
the apps separately. Can anybody here help with that? A mini how-to?
You'd need to separate the files into different packages. Put the core libraries in one package, then separate the binaries and other libraries into other packages. If you use RPM for package management, I can provide an example of how to do that. I don't know how to do packaging on any other system.
I don't use RPM, but I can uncompress rpms. As long as the build scripts are inside the rpm I probably can convert the build scripts to Slackware.
SRPMs (source RPMs) contain the build scripts, and can be installed/unpacked the same as binary RPMs. From talking with others, though, I'm not sure how many distros actually use SRPMs. Some put their spec files (the build script) and sources in either tarballs or version control.
On Nov 22, 2011, at 16:28, Kristopher John Gamrat chaotickjg@gmail.com wrote:
On Tuesday 22 November 2011 04:23:35 pm Darrell Anderson wrote:
Well, then. Looks like I need to learn how to package
the apps separately. Can anybody here help with that? A mini how-to?
You'd need to separate the files into different packages. Put the core libraries in one package, then separate the binaries and other libraries into other packages. If you use RPM for package management, I can provide an example of how to do that. I don't know how to do packaging on any other system.
I don't use RPM, but I can uncompress rpms. As long as the build scripts are inside the rpm I probably can convert the build scripts to Slackware.
SRPMs (source RPMs) contain the build scripts, and can be installed/unpacked the same as binary RPMs. From talking with others, though, I'm not sure how many distros actually use SRPMs. Some put their spec files (the build script) and sources in either tarballs or version control.
All >_> a SRPM gives an RPM ^_^
And most distributions use subpackages for this kind of stuff, so converting build scripts can be tricky. Either that or highly annoying >.<
On Tuesday 22 November 2011 04:48:42 pm Robert Xu wrote:
On Nov 22, 2011, at 16:28, Kristopher John Gamrat chaotickjg@gmail.com wrote:
On Tuesday 22 November 2011 04:23:35 pm Darrell Anderson wrote:
Well, then. Looks like I need to learn how to package
the apps separately. Can anybody here help with that? A mini how-to?
You'd need to separate the files into different packages. Put the core libraries in one package, then separate the binaries and other libraries into other packages. If you use RPM for package management, I can provide an example of how to do that. I don't know how to do packaging on any other system.
I don't use RPM, but I can uncompress rpms. As long as the build scripts are inside the rpm I probably can convert the build scripts to Slackware.
SRPMs (source RPMs) contain the build scripts, and can be installed/unpacked the same as binary RPMs. From talking with others, though, I'm not sure how many distros actually use SRPMs. Some put their spec files (the build script) and sources in either tarballs or version control.
All >_> a SRPM gives an RPM ^_^
Spec files and source code give the RPM, and are included in the SRPM. Any system that uses SRPMs to build the RPMs always unpack the SRPM first to get at the spec files and source code. Not all RPM-based build systems use (or accept) SRPMs, some do.
And most distributions use subpackages for this kind of stuff, so converting build scripts can be tricky. Either that or highly annoying >.<
That's something the package maintainers have to decide -- to convert, or write from scratch.
SRPMs (source RPMs) contain the build scripts, and can be installed/unpacked the same as binary RPMs. From talking with others, though, I'm not sure how many distros actually use SRPMs. Some put their spec files (the build script) and sources in either tarballs or version control.
All I need are some links...
Darrell
On Tuesday 22 November 2011 04:55:24 pm Darrell Anderson wrote:
SRPMs (source RPMs) contain the build scripts, and can be installed/unpacked the same as binary RPMs. From talking with others, though, I'm not sure how many distros actually use SRPMs. Some put their spec files (the build script) and sources in either tarballs or version control.
All I need are some links...
I'm providing links to Ark Linux SRPMs since that is the only distro I'm truly familiar with. This is to their last stable release: http://arklinux.osuosl.org/2008.1/SRPMS/ http://arklinux.osuosl.org/2008.1/SRPMS/koffice-1.6.3-3ark.src.rpm http://arklinux.osuosl.org/2008.1/SRPMS/koffice-i18n-1.3.2-2ark.src.rpm http://arklinux.osuosl.org/2008.1/SRPMS/koffice-i18n-3.5.0-0.473319.1ark.src... http://arklinux.osuosl.org/2008.1/SRPMS/koffice-klipart-stencils-20030823-1a...
Those are KDE3, since 2008.1 was before TDE. Hopefully soon I can start TDE RPMs for our development version. I don't expect the file lists to have changed much.
I don't know the differences between RPMs and whatever Slackware uses, so I don't know how easy it will be to convert.
I'm providing links to Ark Linux SRPMs since that is the only distro I'm truly familiar with. This is to their last stable release: http://arklinux.osuosl.org/2008.1/SRPMS/ http://arklinux.osuosl.org/2008.1/SRPMS/koffice-1.6.3-3ark.src.rpm http://arklinux.osuosl.org/2008.1/SRPMS/koffice-i18n-1.3.2-2ark.src.rpm http://arklinux.osuosl.org/2008.1/SRPMS/koffice-i18n-3.5.0-0.473319.1ark.src... http://arklinux.osuosl.org/2008.1/SRPMS/koffice-klipart-stencils-20030823-1a...
Those are KDE3, since 2008.1 was before TDE. Hopefully soon I can start TDE RPMs for our development version. I don't expect the file lists to have changed much.
I don't know the differences between RPMs and whatever Slackware uses, so I don't know how easy it will be to convert.
Thanks.
And these sources split KOffice into separate packages?
Darrell
On Tuesday 22 November 2011 05:07:24 pm Darrell Anderson wrote:
I'm providing links to Ark Linux SRPMs since that is the only distro I'm truly familiar with. This is to their last stable release: http://arklinux.osuosl.org/2008.1/SRPMS/ http://arklinux.osuosl.org/2008.1/SRPMS/koffice-1.6.3-3ark.src.rpm http://arklinux.osuosl.org/2008.1/SRPMS/koffice-i18n-1.3.2-2ark.src.rpm http://arklinux.osuosl.org/2008.1/SRPMS/koffice-i18n-3.5.0-0.473319.1ark.src... http://arklinux.osuosl.org/2008.1/SRPMS/koffice-klipart-stencils-20030823-1a...
Those are KDE3, since 2008.1 was before TDE. Hopefully soon I can start TDE RPMs for our development version. I don't expect the file lists to have changed much.
I don't know the differences between RPMs and whatever Slackware uses, so I don't know how easy it will be to convert.
Thanks.
And these sources split KOffice into separate packages?
Yes. If you look through their binary section, you'll see the different packages. Do a search for, e.g. kword or krita: http://arklinux.osuosl.org/2008.1/i586/
On 22 November 2011 11:44, Werner Joss werner@hoernerfranzracing.de wrote:
On Tuesday 22 November 2011 03:26:04 Darrell Anderson wrote:
If this suite is advertised as a personal office suite rather than professional the apps remain viable for many Trinity users. The tight integration with TDE is a bonus too.
absolutely, yes. I like kword and kspread well, ligthtweight, fast, well integrated, does (nearly) every thing I need, so far. some quirks though (inconsistent font sizes, e.g.). (I also tried koffice2.x several times, before it became calligra, and it was a complete mess, unusable, data loss etc.). OO, however, is a monster and just plain overkill, I just use it rarely when I have to look at some M$-office documents sent from someone...
I hope KOffice is not removed from the Trinity line, but I am wondering
how
much work is involved to package the apps separately. Likely there would need to be a koffice-base package that contains all the common libraries, headers, etc.
hm, there ARE separate packages, e.g. kspread:
aptitude show kspread-trinity
Paket: kspread-trinity Neu: ja Zustand: Installiert Automatisch installiert: ja Version: 4:3.5.13-0debian9+r1260139+pr4~squeeze Priorität: optional Bereich: kde Verwalter: Timothy Pearson kb9vqf@pearsoncomputing.net Unkomprimierte Größe: 8.303 k Hängt ab von: kdelibs4c2a-trinity (>= 4:3.5.8-1), kexi-trinity (>= 4:3.5.13), koffice-libs-trinity (>= 4:3.5.13), libc6 (>= 2.3.6-6~), libgcc1 (>= 1:4.1.1), libice6 (>= 1:1.0.0), libpng12-0 (>= 1.2.13-4), libqt3-mt (>= 3:3.3.8-d), libsm6, libstdc++6 (>= 4.4.0), libtqtinterface, libx11-6, libxext6, zlib1g (>= 1:1.1.4), koffice-libs-trinity (< 4:3.5.14) Empfiehlt: khelpcenter-trinity | koffice-trinity-doc-html (= 4:3.5.13-0debian9+r1260139+pr4~squeeze) Beschreibung: a spreadsheet for the KDE Office Suite [Trinity] KSpread is a powerful spreadsheet application. It is scriptable and provides both table-oriented sheets and support for complex mathematical formulae and statistics.
This package is part of the KDE Office Suite.
While I do think certain applications from the KOffice suite are not replaceable, I do think that KWord and our database programs are replaceable.
An important thing to remember is that the development team has so much time. How long do we keep the Koffice suite before it is incompatible with others? Does LibreOffice provide what we need? Does KOffice do what we need?
Obviously I am not suggesting we drop KOffice or anything of that nature, but one does need to plan ahead.
Calvin
-
/dev/ammo42 -
Calvin Morrison -
Darrell Anderson -
Kristopher John Gamrat -
Laurent Dard -
Robert Xu -
Serghei Amelian -
Timothy Pearson -
Werner Joss