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)? 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 Tuesday 22 November 2011 01:13:50 pm Calvin Morrison wrote: 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/

On Tuesday 22 November 2011 01:31:28 pm Calvin Morrison wrote: 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. -- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/

On Tuesday 22 November 2011 01:42:46 pm Calvin Morrison wrote: 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. So why are we still having it? O.o -- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/

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. 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... 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

On Tuesday 22 November 2011 03:01:55 pm Timothy Pearson wrote: 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/

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. I'm including OO just to be nice. We still need an integrated TDE file picker. 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

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. 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. Likewise. Wrangling with you young whipper snappers keeps my mind sharper than I might otherwise be. :) Darrell

No insult taken! Psychologists and socioligists have shown many times that most humans do not act rationally, despite the claims otherwise. Darrell

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 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. 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." 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 19:31:28 Calvin Morrison wrote: 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 23 November 2011 11:26, Kristopher John Gamrat <chaotickjg(a)gmail.com>wrote;wrote: 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 23 November 2011 11:42, Kristopher John Gamrat <chaotickjg(a)gmail.com>wrote;wrote: Then now is the time to learn :) We need developers and the more the better. Calvin

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. :) 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 18:13:32 Darrell Anderson wrote: 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 18:34:58 Kristopher John Gamrat wrote: 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

On Wednesday 23 November 2011 18:34:26 Werner Joss wrote: 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

On Wednesday 23 November 2011 20:00:03 Darrell Anderson wrote: probably, yes. the original site doesn't exist anymore, IMHO. wayback machine could help, maybe. werner

Le Wed, 23 Nov 2011 09:13:32 -0800 (PST), Darrell Anderson <humanreadable(a)yahoo.com> a écrit : 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.

On Tuesday 22 November 2011 12:06:51 pm Darrell Anderson wrote: 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. 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. 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. -- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/

On Tuesday 22 November 2011 04:23:35 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. -- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/

On Tuesday 22 November 2011 04:48:42 pm Robert Xu wrote: 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. That's something the package maintainers have to decide -- to convert, or write from scratch. -- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/

On Tuesday 22 November 2011 04:55: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.sr… http://arklinux.osuosl.org/2008.1/SRPMS/koffice-klipart-stencils-20030823-1… 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. -- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/

On Tuesday 22 November 2011 05:07:24 pm Darrell Anderson wrote: 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/ -- Kristopher Gamrat Ark Linux webmaster http://www.arklinux.org/