bugGNUstep - Bugs: bug #21229, Gorm cannot load GormDocument.gorm...

Group
 
 

bug #21229: Gorm cannot load GormDocument.gorm because cairo backend does not implement DPSshfill

Submitter:  -Deleted Account- <yjchen>
Submitted:  Tue 02 Oct 2007 10:42:06 PM UTC
   
 
Category:  Backend Severity:  3 - Normal
Item Group:  Change Request Status:  Fixed
Privacy:  Public Assigned to:  FredKiefer
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 09 Oct 2007 10:47:39 PM UTC, comment #5: 

Although I still believe this problem was caused by something eles, I added an implementation of DPSshfill to gsc. That way the problem should be resolved now.

Fred Kiefer <FredKiefer>
Group Member
Fri 05 Oct 2007 04:54:36 PM UTC, comment #4: 

This is really strange now. Of course I cannot reproduce it with "New Application" in Gorm. And your posting also suggests that you don't get it all the time in Gorm.
Could you send me the NIB file you tried to load?

Is any of the theming engines you may have loaded using DPSshfill:? As far as I know it is not present anywhere in GNUstep itself.

One final possibity, did you forget to recompile Gorm after building new gui version?

I am half way trhough building the DPSshfill: method for the other backends, but I am almost sure this isn't needed.

Fred Kiefer <FredKiefer>
Group Member
Fri 05 Oct 2007 03:24:15 PM UTC, comment #3: 

Well, I didn't use DPSshfill in my application.
This is a bug showing up when I try to use Gorm with cairo backend recently.
Actually only that gorm file is affected, but not others.
So it is either a problem of cairo backend, or a problem of gorm file.
If you use latest cairo backend and Gorm to create "New Application",
you should be able to reproduce it.

Yen-Ju

-Deleted Account- <yjchen>
Fri 05 Oct 2007 02:22:18 PM UTC, comment #2: 

I was wrong in my last comment. Alexanders code take a shade definition, but only uses the function of it (shading type 1, function type 0). So it is a proper shade operation. It also determines the result rectangle from this function (taking the domain of the function). So it should be possible to implement it more or less efficient for the other backends as well.

Now the only thing that stands against a general implementation is my feeling that shfill is not what we are really looking for.

Fred Kiefer <FredKiefer>
Group Member
Fri 05 Oct 2007 01:54:40 PM UTC, comment #1: 

I don't quite understand what you are complaining about. Is it that the cairo (as well as the xlib and the windows) backend don't implement the DPSshfill: method or is it that Gorm wont load a NIB because of this?

As you put this in as a backend bug, most likely the later is the case. Now what is the DPSshfill: method? It is an extension specially there in the art backend. It is based on the Postscript shfill operator, but takes a function dictionary as input instead of a shading dictionary as a proper shfill operator would.
I had a quick go on the code and it would be easy to move the implementation of the function itself up into gsc. The problematic part here is that the shfill operator works on the clip area. The art backend is the only backend where we have direct control over the clip path. In the other backends we pass on the clip path to the underlying drawing system and forget about it. This means, we are not able to easily fill the clip path with the result of the function call.
We could of course fill the whole result area with the function and clipping would take care of not changing anything outside the allowed range, but this is a wasting of drawing time.

Another solution would be to abanden the DPSshfill method and find out, what it was used for and replace this with an operation that is easy to implement on most backends. I would expect that people used this method to implement colour gradients and there are better ways to get the same result.

What does your application use it for?



Fred Kiefer <FredKiefer>
Group Member
Tue 02 Oct 2007 10:42:06 PM UTC, original submission:  

Below is the error message with trunk of GNUstep and Gorm.
A quick scan on back/Source/cairo/ shows there is no implementation of DPSshfill. Art backend has one, though.

2007-10-02 15:38:22.367 Gorm[4342] Exception occured while loading model: subclass CairoContext(instance) should override DPSshfill:
2007-10-02 15:38:22.368 Gorm[4342] Failed to load Gorm
2007-10-02 15:38:22.369 Gorm[4342] Could not load Gorm file: /usr/local/GNUstep/System/Applications/Gorm.app/Resources/English.lproj/GormDocument.gorm
2007-10-02 15:38:22.369 Gorm[4342] NSWindowController: could not load nib named GormDocument.nib

-Deleted Account- <yjchen>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by FredKiefer (Posted a comment)
  • -email is unavailable- added by yjchen (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2008-11-29 FredKiefer Open/ClosedIn Test Closed
    2007-10-09 FredKiefer StatusNone Fixed
        Assigned toNone FredKiefer
        Open/ClosedOpen In Test
    2007-10-05 FredKiefer Item GroupBug Change Request

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code