随着如 LibreOffice 的宣布，常会有一系列关于项目方向的激进想法涌来。显然! LibreOffice 不会立刻重写整个代码库，但这是个讨论新想法的机会——所以才有了这个页面。请注意，这是由大家建立的非承诺性的列表，所以不要因为本页的内容而离开，认为这就是 LO 将要发展的方向（或者甚至认为是希望执行的计划）。
|This page (may) contain content that is old and/or out of date.
If you have experience in this area, please review this page for accuracy. Reason: see updates and more ideas at the English page at Development/Crazy Ideas.
扩展 LibreOffice 支持的平台
探索 LibreOffice 对 MS Office 的支持是否可以库形式进行
想法: It is acknowledged as being difficult, but explore what it might take to rework !LibreOffice's MS Office support into libraries that could be shared by other open source office projects. Can it be done at all, or is the required logic too deeply specific to each open source project's own internal logic and framework?
使用 Qt 部件界面替代所有界面代码
想法: Rework !LibreOffice to use the Qt widgets for its GUI, instead of the current approaches to get native appearance. Would almost certainly involve massive reworking of all the interface code - around 1 million lines. It would also make !LibreOffice depend on another huge piece of code owned by a single corporation with (C) assignment: unclear that this is a positive move though the GUI would look better.
评论: Yes, it would look better, although only on KDE-using distros. How would it look in GNOME? If unetbootin and Skype are anything to go by, you won't be able to see half the menu text... Spacebat 2010-10-13T16:10:43 (CEST)
Of course it's something of a matter of opinion, but with newer Qt4 releases it is quite possible to obtain a pleasing, clean look with Qt without running in KDE. Dunno if it respects Gnome themes directly, but this looks interesting: https://blog.qt.io/2008/05/13/introducing-qgtkstyle Anyway, Qt is certainly the closest thing I know of to a robust, fully cross platform GUI toolkit. To respond as to whether Qt would be an improvement over the current situation - currently LibreOffice must do all the work of maintaining its own cross platform widget solution. Even if Qt someday must be forked, at least there are a vast array of tools in real world use that rely on it. The incentive to maintain a fork properly would extend far beyond the LibreOffice project, so even in that (worst case) scenario LibreOffice would get more help on cross-platform GUI toolkit maintainance than it does with its own current internal solution. I might also mention that so far the trend of Qt has been consistently making the toolkit MORE free, not less, and unlike the OO.org case there hasn't been much visible trouble or lack of progress due to Trolltech/Nokia running the development. Bottom line is that cross platform GUI work has to be done, and Qt seems to have the best solution to that problem of any currently active project - why not leverage that effort and community buy-in? A better looking GUI is an important metric for a project like LibreOffice, whose users are going to expect GUI polish as a matter of course.
移除 java 组件
想法: Some think java is a slow memory hog, others think it is a legal swamp that invites lawsuits. Neither might be true, but some developers have nevertheless xpressed their desire to remove java usage in LO over time. OUr build master says, the first step is to make compilation work with --without-java (it currently fails), and then go to replace components by non-java components. E.g. the xslt processing is being done with java, apparently and libxslt (which is already included in LO) could be used to do the job.
Currently libreoffice contains an old and heavily patched tarball of seamonkey. YES! That websuite that include everything. It uses that to access the Mozilla/Thunderbird addressbook, uses its LDAP backend for address searches and I believe as a LDAP config backend. Investigating if we can't do away with it, or make it easily optional would be great for the sake of quicker compile times. Heck, I mean compiling a web-suite just in order to get LDAP access (which I don't even need at all!)
增加 WordPerfect 功能如代码显示（RevealCodes）与隐藏文本（HiddenText）
See i#3395 for detailed description, some patches and how much wanted this feature is (it was filed in 2002 and has 176 votes).
When MS copied them into Word it broke them horribly for power users.
They ran a survey asking what people used Reveal Codes for and 90% said they "use it for checking formatting". The remaining ten percent were probably power users, who use it as their main editing window (like me). It is an *incredibly* powerful tool for a power user. Given that ODF is XML-based it shouldn't be that difficult to get something like that working.
And Hidden Text is a nifty little feature too ... Word has something similar in "comments", but the problem there is comments don't print. Hidden text (in WordPerfect) is just another font attribute, but controlled by an entry in the "view" menu. If it's on, hidden text can be seen on screen and prints on the printer. If it's off, it's only visible (as a marker) in the Reveal Codes window. Great for doing quizes :-) where you put the answers in in hidden text, and then you can print the document with it off for the question sheet, and again with it on for the answer sheet.
我在构想有这样的服务可负责格式的不兼容性： 上传导致问题的 .docx/.odt 文件。办公套件后端自动附加文档在 LO/OOo/MS Office 2010 中显示情况的屏幕截图。不必要求用户注册。志愿者可帮助挖掘文档的相关部分并创建最小测试样本，最终用来提交为“真实的”bug 或转移至已有 bug，可作为验证 bug 修正情况的测试样本。