bigger.
The LyXText class does not necessarily need to change
a lot, it could be per-view. However all the special
- code in it needs to be (re)moved. Also a lot of the
+ code in it needs to be (re)moved. Also a lot of the
functionality needs to be relocated.
- o Switch to LaTeX as fileformat
- Will ease move from latex to LyX a lot.
- Also will let people work both in (ex) emacs
- and LyX on the same files.
o GUI independence.
Should be a compile time switch what gui (toolkit)
you wish to use. We are going to support Xforms first,
no view being able to coexist with other views or alone)
We will do this by providing an interface all the
toolkits will need to follow. Functions that the LyX
- core will expect to be there.
+ core will expect to be there.
When these three is finished, we will probably declare a code freeze
and try to release a new version. Hopefully other features has also
o always try to use POSIX commands.
o switch to use POSIX signals
o make as much as possible of the code reentreanant(?)
- should make it easier to move to threads later.
- o signal slot mechanism (borrowed from GTK-- project)
- better interface, leaner code, typesafe. I have
- been using this for another project and it works
+ should make it easier to move to threads later. Albeit
+ this is not a huge goal we have some parts of the code
+ that would benefit from threads. (forking is not that
+ nice...)
+ o signal slot mechanism
+ We are going to use the signal/slot implementation
+ found in libsigc++. This will hopefully give us better
+ interface, leaner code, typesafe "callbacks". I have
+ been using signal/slots for other projects and it works
like a charm.
o other code rewrites to make multiple buffers/windows
possible, without too much hassle.
- - get rid of most of the global variables.
- - non shared variables in shared structures
- (i.e. the cursor in the text class)
+ - get rid of most of the global variables. In
+ perticular current_view is a problem.
+ - non shared variables in shared structures
o make source documentation better. Remember that the better
we document LyX internals the easier is it for new
developers to begin working on LyX.
- ensure that not too many commands are executed at
the same time.
- ensure that non-compatible commands are running at
- the same time.
+ the same time.
- to setup file descriptors where communicating with
the processes can take place.
o pass an inforeceiver around in the object structure.
o better version control (both document and file wise)
- version.sty
- cvs
- - sccs
- o I am sure mathed improvements. (Alejandro's department)
- - better macro support
- - better amsmath support
+ - sccs
o character styles (similar to emph and noun)
Will make a lot of small things conceptual instead of
specific. Will be alot easier to change the
- replace & find next
- replace & find previous
We should perhaps try to make the interface a bit
- emacs like, that should at least give us the
+ emacs like, that should at least give us the
features we want.
o improved template support.
o collapse "New" and "New from Template" into one item.
o the "LyX-Code" environment should be removed. Add a verbatim
environment instead.
o tabbing support
+ This would be a special inset that is line based (no
+ breaking of lines), where tabstops can be set and used.
+
o picture support
+ A special insets with some basic drawing
+ capabilities.
+
o better graphics support
+ I have begun doing something about this. There are
+ several things here that need to be dont. We have alreay
+ decided to use graphicx.sty instead of graphics.sty. This
+ makes several things easier. There is also some work in
+ progress to separate the inset and the creation of the Xpm
+ (Ximages) completely. I imagin this as the InsetGraphics
+ asking a GraphicsCache for a graphics with certain
+ parameters set and get a handle to the finished
+ transformation of the graphics. Hopefully this should make
+ it quite easy for LyX to support several/many graphics
+ formats, both on screen and on hard copy.
+
o rotating and scaling of text
o PSTricks (we should be able to support some of this package)
o better reference support
process.
o online configuration
So that users should not need to edit lyxrc
- manualy
+ manualy. This has now been "half" done; it is now
+ possible to save the current configuration with the
+ lyx command "preferences-save". We need to add code so
+ that the preferences can be set from inside LyX too.
o better fontsupport
T1-lib font renderer.
o better latex code quality
This means reading LaTeX books to get an better idea
- on how things are done in the latex world.
+ on how things are done in the latex world.
o perhaps find better names for the paragraph styles
"paragraph" and "subparagraph"
o support for filecontents
o better babel support
- make it possible to tune the language strings
- the possibility for several languages in the same
- document.
+ document.
o title page support
o draft copy
- draftcopy.sty
- make it indepentent of the GUI
- prob: concurrency (locks)
o other packages to support:
+ - listings.sty
- keyval (we should not use it directly, but know how
to parse options for it.)
- here.sty
projects / lyx.git / blobdiff