gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Away for a week


From: Alexander Malmberg
Subject: Re: Away for a week
Date: Fri, 22 Aug 2003 17:19:45 +0200

Fred Kiefer wrote:
[snip]
> There are different areas, where I have half thought up extensions for
> GNUstep. I will list some of them in this mail to get your comments
> while I am away:
> 
> 1. Support for image colours. This feature would make most of the
> current themes support obsolete, as much of it would be obtainable by
> colour lists. The big missing part is the setting and drawing of image
> colours in the back end. To implement this we could use simple image
> tileing, similar to what is used in the themes bundle.

I wouldn't really call this an extension. We already have this in DPS in
the form of pattern colors and shaders. We'd just need to define the
backend interface properly (eg. the types used in the dictionary
arguments for makepattern), and implement something on top of that in
NSColor.

Some of the pattern/shader types will require a lot of work to implement
in the backend, so most backends probably wouldn't support all types
(I'm not exactly itching to implement eg. tensor-product patch mesh
shaders; someone would need to give me a very good reason to do that :).

However, if there's an interface, I could do correct but slow
implementations of type 2 patterns and type 1, 2, and 3 shaders in
back-art (and others if someone convinces me :).

(back-art already handles type 1 shaders (with type 0 functions), but
only using shfill, not as colors. Fortunately, shfill and clipping paths
together cover many (most?) things you'd want pattern colors for.)

Anyway, although this is neat stuff, I don't think it's a high priority
(otoh, I think it's a very high priority to do it right, if it is done).

> 2. Better interaction with different windows manager. This is a bit
> harder, as it has loads of different aspects. First there is [NSScreen
> visibleFrame] and the use of it. Second the window borders. Third there
> is all the stuff from freedesktop.org.

I suspect that this would involve a fair amount of work on non-GNUstep
code. An important issue for those stuck with X, though. Currently,
GNUstep and window managers easily become confused about where focus and
windows should go.

> 3. I did promise some work on the Windows backend. Is there really 
> anybody interested in that?

I don't have much interest in it, but I strongly suspect that there are
others who do.

> 4. Clean up of the text system.

This is something I'm working on, although slowly. Since cleanups don't
affect correctness, I don't think it's a high priority. (OTOH,
documentation is, so I really should hurry up with that.)

> 5. The old boring cleanup and bug fixes on GUI.

No lack of things to do here. :)

> 6. There is also the idea that I did write a few months ago in a mail to
> Richard, that we should use gdomap to implement more of the GUI general
> interaction methods (like hideOtherApplications:) by exporting the list
> of the running GNUstep applications with an interface similar to what
> gets used for the donames() function. This would be used by the
> GSServiceManager to provide some methods for NSApplication and NSWorkspace.

This is interesting for the desktops built on GNUstep, but I don't think
this belongs in core/ itself. In particular, gdomap is the wrong place
for this since gdomap is a -base daemon (a suid one at that, so it
should do only one thing, but do it in a very secure way), and not
everyone runs gdomap. 

> This is a lot more than I am able do for the rest of this year, so
> please give me your priorities.

I'd add printing. Postscript generation seems to work ok, but the NSView
printing machinery is broken (TextEdit is a good test case here), and
then there's the issue of getting the postscript to the printer. This
is, IMHO, a very high priority.

- Alexander Malmberg




reply via email to

[Prev in Thread] Current Thread [Next in Thread]