mirror of
https://github.com/gnustep/libs-gui.git
synced 2025-04-28 14:11:00 +00:00
Font change, other minor this.
git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/gui/trunk@3624 72102866-910b-0410-8b05-ffd578937521
This commit is contained in:
parent
5b392929a2
commit
beed962667
2 changed files with 4 additions and 94 deletions
|
@ -1,3 +1,7 @@
|
||||||
|
Fri Jan 29 15:32:48 1999 Adam Fedor <fedor@ultra.doc.com>
|
||||||
|
|
||||||
|
* Documentation/todo.tmpl.texi: Update.
|
||||||
|
|
||||||
1999-01-28 Adam Fedor <fedor@doc.com>
|
1999-01-28 Adam Fedor <fedor@doc.com>
|
||||||
|
|
||||||
* Model/GNUmakefile (libgmodel_OBJC_FILES): Add GMArchiver.m.
|
* Model/GNUmakefile (libgmodel_OBJC_FILES): Add GMArchiver.m.
|
||||||
|
|
|
@ -17,102 +17,8 @@ help is greatly appreciated. Send email to @email{scottc@@net-community.com}.
|
||||||
@item Consolodate examples & tests [3, OpenStep] (980913).
|
@item Consolodate examples & tests [3, OpenStep] (980913).
|
||||||
Also fix or document whatever bugs are there.
|
Also fix or document whatever bugs are there.
|
||||||
|
|
||||||
@item @emph{Cut gradient code out of WindowMaker and insert in menus} [4,
|
|
||||||
WindowMaker] (980913).
|
|
||||||
|
|
||||||
@item @emph{Define interface between GNUstep and window manager} [7, X11 window
|
|
||||||
managers] (980912).
|
|
||||||
Work with WindowMaker folks on this.
|
|
||||||
|
|
||||||
@item @emph{Need to write an interface for a simple drawing engine} [7, PS, X11] (980913).
|
|
||||||
So we can maintain compatibility between DPS backends and other
|
|
||||||
backends, and have a unified printing mechanism.
|
|
||||||
|
|
||||||
@item Need an rtf parser [6 - Objective-C, RTF] (980820).
|
@item Need an rtf parser [6 - Objective-C, RTF] (980820).
|
||||||
|
|
||||||
@item
|
|
||||||
flipped views; should be really simple to implement, using a
|
|
||||||
simple Postscript transformation (see how scalation and
|
|
||||||
rotation
|
|
||||||
are implemented in NSView), but it probably has implications in
|
|
||||||
how other classes are implemented - NSMatrix, NSClipView and
|
|
||||||
NSScrollView are some of them. I don't have enough time to
|
|
||||||
implement it, if somebody else can come up with an implementation
|
|
||||||
and test all the implications it would be great. Flipped views
|
|
||||||
affect for example the look of NSBrowser right now, it will work
|
|
||||||
as expected when flipped views will be available.
|
|
||||||
|
|
||||||
@item
|
|
||||||
the implementation for NSImage should be completed. The current
|
|
||||||
implementation is buggy, that's why you can see those ugly arrow
|
|
||||||
images inside the scroll buttons. All the image representations
|
|
||||||
should be added, including full support for various TIFF formats
|
|
||||||
and for EPS images.
|
|
||||||
|
|
||||||
@item
|
|
||||||
NSColorList should be implemented such that it stores the color
|
|
||||||
lists into an implementation independent format. The current
|
|
||||||
implementation uses NSArchiver which is not good because the files
|
|
||||||
are dependent on the Foundation library used. A simple ASCII file
|
|
||||||
should be sufficient; alternatively Foundation .strings or
|
|
||||||
property list files could be used.
|
|
||||||
|
|
||||||
@item
|
|
||||||
various panels should be implemented: NSOpenPanel, NSSavePanel,
|
|
||||||
NSColorPanel, NSFontPanel. This should be really simple once we
|
|
||||||
have model handling. The implementation of a panel should have
|
|
||||||
associated with it a model file which contains the description of
|
|
||||||
the graphical objects inside a panel; the behavior is implemented
|
|
||||||
by the corresponding class. Having the model file describe the
|
|
||||||
aspect of the panel makes the look of panel independent on the
|
|
||||||
actual backend, each backend could come with its own model file to
|
|
||||||
describe a panel. This is in theory, most probably some minimal
|
|
||||||
support in backend would still be required.
|
|
||||||
|
|
||||||
@item
|
|
||||||
automatic resizing of views should be done. Also pretty simple to
|
|
||||||
do.
|
|
||||||
|
|
||||||
@item
|
|
||||||
sending of -display to a view doesn't work as expected because the
|
|
||||||
optimization I've done for displaying and flushing of windows
|
|
||||||
doesn't mark the view as needing flush, in the case of buffered
|
|
||||||
windows; you should use -setNeedsDisplay: instead. This is a known
|
|
||||||
problem and should be fixed.
|
|
||||||
|
|
||||||
@item
|
|
||||||
the interaction between the X/DPS library and the window manager
|
|
||||||
should be defined so that we can implement modal windows, window
|
|
||||||
ordering (which should really not depend on the window manager),
|
|
||||||
drag&drop, the display of window decorations and the handling of
|
|
||||||
window resizing, closing and miniaturizing.
|
|
||||||
|
|
||||||
@item
|
|
||||||
the NSFormCell should be able to edit the text value
|
|
||||||
|
|
||||||
@item
|
|
||||||
the NSTextField class should be finished to make the cursor flush.
|
|
||||||
should also be hidden when the text field resigns as
|
|
||||||
first responder. Another thing to be done is to handle text
|
|
||||||
selections. Cursor flushing is fairly simple to implement with
|
|
||||||
timer events; selection should also be simple enough.
|
|
||||||
|
|
||||||
@item @emph{NSText} [8, NSText] (980101)
|
|
||||||
the biggest challange is the text system. Some work has been done
|
|
||||||
by ANOQ of the Sun, but it is a mixture between the old and the
|
|
||||||
new API for NSText from the newer OPENSTEP. In my opinion we
|
|
||||||
should try implement the new API only, the old one is too hard to
|
|
||||||
program and extend by users. Also the Johnny's implementation is
|
|
||||||
view-only, you can't really use the code to edit the text. My
|
|
||||||
estimate for a fairly complete version of it would be 2 good
|
|
||||||
people working full time for 3-4 months.
|
|
||||||
|
|
||||||
@item Implement drag and drop [6, drag&drop interfaces&standards] (980101)
|
|
||||||
Drag and drop/pasteboard framework. Is there a way this can be done so
|
|
||||||
that all GNU programs can take advantage of it and not just GNUstep?
|
|
||||||
That would be optimal because GNUstep and non-GNUstep programs would then
|
|
||||||
be able to partially interoperate.
|
|
||||||
|
|
||||||
@item
|
@item
|
||||||
Expand the image handling capabilities beyond OpenStep. There is no
|
Expand the image handling capabilities beyond OpenStep. There is no
|
||||||
reason why we must limit ourselves to EPS and TIFF bitmaps, we should
|
reason why we must limit ourselves to EPS and TIFF bitmaps, we should
|
||||||
|
|
Loading…
Reference in a new issue