[bug #21203] Cairo backend does not display

[Fred Kiefer]

Update of bug #21203 (project gnustep):

  Status:None => Fixed  
 Assigned to:None => FredKiefer 
 Open/Closed:Open => In Test

___

Follow-up Comment #3:

I changed this method to take the depth value from the window device. This is
what should have happend in the first place and what Nicolas and I had agreed
on during Alpenstep.

No idea why it ever was implemented differently.

The whole concept of the depth_info seems a bit strange to me. The values
that get used there in art don't match my concept of window depth.

Please give the new code a try and report back.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Fred Kiefer]

Update of bug #21229 (project gnustep):

  Item Group: Bug => Change Request 

___

Follow-up 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?




___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21200] Cairo version dependency and other nuisances

[Fred Kiefer]

Follow-up Comment #7, bug #21200 (project gnustep):

Yes, this issue was introduced into GNUstep when Nicolas Roads extended the
cairo backend to use 32 bit drawing depth, when available on the computer.
This in itself is something good, as this will allow us to implement
transparent window contents. But as with any new feature there were a few
problems that only show up in special configurations. We need to carefully
inspect each of them and find a general solution.
The change I did today looked like one to me. It may still not be sufficent,
but could you please give it a try and report back on the result. And if
possible, post your reply to bug #21203 :-(

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Fred Kiefer]

Follow-up Comment #2, bug #21229 (project gnustep):

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.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Fred Kiefer]

Follow-up Comment #4, bug #21229 (project gnustep):

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.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21279] GSFunction fails to compile

[Fred Kiefer]

Update of bug #21279 (project gnustep):

  Status:None => Fixed  
 Assigned to:None => FredKiefer 
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

Sorry for breaking you compilation, but this worked perfectly here withou any
warning. Which version of gcc are you using on that machine? As you can see in
the source code the reported method is implemented in the super class just a
few lines above.
To work around this problem I added a declaration of that method in the
header file. This should allow you to compile again.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #19352] Cairo: bad EPS from NSView_dataWithEPSInsideRect:

[Fred Kiefer]

Follow-up Comment #6, bug #19352 (project gnustep):

I had a look at the cairo PS file. It surely isn't a bitmap format. If you
have a closer look you will see a the lineto and moveto commands you would
expect. The whole file is incorrectly scaled and the font looks ugly. As far
as I can see from the PS file cairo has to create the glyphs of the font by
defining an image per glyph. This is a very bad sign. It could mean that cairo
has no idea, which replacement PS font to use for your screen font.
If I remember correctly you had some problems to get a proper screen font
from the cairo backend. Which font did you choose in the end? Was it a bitmap
font? This could explain the whole behaviour.
There is a big difference between art, which uses nfont where you may define
the font to PS mapping yourself and the cairo backend, which relies on cairo
to replace the font.

Could you look into the scaling problem yourself? Printing isnt currently on
my priority list and I remember you doing some great stuff there before.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21262] Creeping menus

[Fred Kiefer]

Update of bug #21262 (project gnustep):

  Status:None => Invalid
 Open/Closed:Open => Closed 

___

Follow-up Comment #4:

Closed as it was reported to be a virtualisation issue.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21273] Cairo: combo box menus blacked out

[Fred Kiefer]

Update of bug #21273 (project gnustep):

  Status:None => Confirmed  
 Assigned to:None => FredKiefer 

___

Follow-up Comment #1:

The behaviour I get from combo boxes is a bit different. They are displayed
correctly, but don't seem to interact with the user. In reality they interact
correctly but wont display the changed data.

This could be caused by the cairo backend not handling non retained windows
correctly. This would also explain, why dragging a control in Gorm shows the
wrong image. 
Most likely it is just some sort of flushing that is missing here, but
where

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21301] Uninitialized variable in NSDecimalMultiplyByPowerOf10

[Fred Kiefer]

Update of bug #21301 (project gnustep):

Category:None => Base/Foundation
  Item Group:None => Bug
  Status:None => Fixed  
 Assigned to:None => FredKiefer 
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

I moved the code, which gives a result quite similar to your patch.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

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

[Fred Kiefer]

Update of bug #21229 (project gnustep):

  Status:None => Fixed  
 Assigned to:None => FredKiefer 
 Open/Closed:Open => In Test

___

Follow-up 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.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21173] unimplemented overide in XGFontInfo

[Fred Kiefer]

Follow-up Comment #3, bug #21173 (project gnustep):

Added a cairo implementation for this method.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #18128] Art backend does not draw properly on Ubuntu 6.10

[Fred Kiefer]

Update of bug #18128 (project gnustep):

 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Closed as requested by initiator. The problem that the art backend has an
issue with 16 bit colours still remains.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #13721] Fedora Core 4 gcc4 crash

[Fred Kiefer]

Update of bug #13721 (project gnustep):

 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Closed as there was no further input from originator.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #16262] GScups Generate Invalid font Names

[Fred Kiefer]

Update of bug #16262 (project gnustep):

Category:  Gui/AppKit => Backend

___

Follow-up Comment #4:

Changed category to backend

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #12374] Windows move down

[Fred Kiefer]

Follow-up Comment #1, bug #12374 (project gnustep):

Could ypu please try again with a recent version of GNUstep?
This issue should be resolved.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #13592] All windows of GNUstep applications share same WM_CLASS

[Fred Kiefer]

Update of bug #13592 (project gnustep):

  Status:None => Wont Fix   
 Assigned to:None => FredKiefer 
 Open/Closed:Open => Declined   

___

Follow-up Comment #2:

I am decling this request as the originator never added detail information of
what he wanted. 
The usage of a window in GNUstep can only be determined via the window level
and this may change, whereas the window class of a window is not allowed to
change. So one isn't a great match for the other.
What we need to support in GNUstep is a better way to tell the window
manager, what a window is being used for. Here we try to use EWMH, which
should more or less already work.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #16302] gnustep-back-svn 22756 compile error(in Cygwin)

[Fred Kiefer]

Follow-up Comment #2, bug #16302 (project gnustep):

This combination used to work. It was the original one I implemented :-)

I think it should be sufficient to change this method to just call callback:
in the Cygwin case. That is, put the usage of ET_WINMSG into 
#ifndef__CYGWIN__

#endif 

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #17020] compiler warning for convert.m

[Fred Kiefer]

Update of bug #17020 (project gnustep):

  Status:None => Fixed  
 Assigned to:None => FredKiefer 
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

resolved

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #17021] compiler warning for raster.c

[Fred Kiefer]

Update of bug #17021 (project gnustep):

  Status:None => Fixed  
 Assigned to:None => FredKiefer 
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Resolved

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21279] GSFunction fails to compile

[Fred Kiefer]

Update of bug #21279 (project gnustep):

 Open/Closed: In Test => Closed 


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21203] Cairo backend does not display

[Fred Kiefer]

Update of bug #21203 (project gnustep):

 Open/Closed: In Test => Closed 


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #11976] Window does not properly miniaturize when GSAppOwnsMiniwindow == YES and GSX11HandlesWindowDecorations == NO

[Fred Kiefer]

Update of bug #11976 (project gnustep):

 Open/Closed: In Test => Closed 


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #16218] Problem with NSKeyedArchiver

[Fred Kiefer]

Update of bug #16218 (project gnustep):

 Open/Closed: In Test => Closed 


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #19352] Cairo: bad EPS from NSView_dataWithEPSInsideRect:

[Fred Kiefer]

Follow-up Comment #9, bug #19352 (project gnustep):

Thank you for this additional information. Especially the hint to the moveto
could be helpful. What I am wondering about is that you only get the clip
problems when generating Postscript, doing exactly the same operations in a
window works. This could mean that we do something wrong while printing or
that cairo itself has a problem here.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #19352] Cairo: bad EPS from NSView_dataWithEPSInsideRect:

[Fred Kiefer]

Follow-up Comment #10, bug #19352 (project gnustep):

I wrote a small test program and this shows that the problem with the clip
copying is completely within cairo. Here is the code:

#include 
#include 
#include 

int 
main (int argc, const char *argv[])
{
  cairo_status_t status;
  cairo_t *ct;
  cairo_surface_t *surface;
  cairo_rectangle_list_t *clip_rects;
 
  surface = cairo_ps_surface_create("test.ps", 100, 100);
  status = cairo_surface_status(surface);
  if (status != CAIRO_STATUS_SUCCESS)
{
  printf("Cairo status '%s' for surfacen",
cairo_status_to_string(status));
  return 0;
}

  ct = cairo_create(surface);
  status = cairo_status(ct);
  if (status != CAIRO_STATUS_SUCCESS)
{
  printf("Cairo status '%s' for contextn",
cairo_status_to_string(status));
  return 0;
}

  cairo_reset_clip(ct);
  cairo_rectangle(ct, 10, 10, 80, 80);
  cairo_clip(ct);
  clip_rects = cairo_copy_clip_rectangle_list(ct);
  status = clip_rects->status;
  if (status != CAIRO_STATUS_SUCCESS)
{
  printf("Cairo status '%s' in copy clipn",
cairo_status_to_string(status));
}

  cairo_destroy(ct);
  cairo_surface_destroy(surface);
}


Compile with the usual command (eg. gcc -I/usr/local/include/cairo cairo.c
-L/usr/local/lib -L/usr/X11R6/lib -lcairo -lm -lfreetype -lz -lfontconfig
-lexpat -lpng12 -lXrender -lX11 -lpthread -o cairo_test)

THis leaves only the positioning of the draw area to be resolved in GNUstep.


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #19352] Cairo: bad EPS from NSView_dataWithEPSInsideRect:

[Fred Kiefer]

Follow-up Comment #12, bug #19352 (project gnustep):

Sorry, but my test code shows that there is a problem in cairo and this needs
to be resolved.

As for the idea of replacing copy with save/restore I had that before and
even tried it in code. There are various issues with this approach. First, the
cairo implementation is a stack only, but in GNUstep we need to access stored
gstates (for windows and views). This is just not possible in cairo.
Second, cairo does not store the path on the stack, we would need to keep
this on a separate stack.
Third, I have no idea if save would copy the clip region correctly for PS.

Your last note I did not understand :-(

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21273] Cairo: combo box menus blacked out

[Fred Kiefer]

Update of bug #21273 (project gnustep):

  Status:   Confirmed => Fixed  
 Open/Closed:Open => In Test

___

Follow-up Comment #3:

I added a hack to work around this problem. It is not the proper solution,
but I cannot figure out, where the current code goes wrong. In the cairo
backend we do the same things as the art backend, still it works there and
fails here.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #19639] Hidden class list in document window

[Fred Kiefer]

Update of bug #19639 (project gnustep):

  Status: In Progress => Fixed  
 Open/Closed:Open => Closed 

___

Follow-up Comment #3:

Reported as closed by user.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #17112] Unarchiving XML-based nibs containing control characters fails....

[Fred Kiefer]

Update of bug #17112 (project gnustep):

 Open/Closed: In Test => Open   

___

Follow-up Comment #8:

This still fails for me. When I try to load the provided NIB file I get:
at line: 8209 column: 11 ... PCDATA invalid Char value 27

Now line 8209 looks like this:
 
Emacs displays the string as "^[", so we are still talking about the ESC
here.

I don't get any error message from the second XML parser, so I have no glue,
why this is failing.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #19352] Cairo: bad EPS from NSView_dataWithEPSInsideRect:

[Fred Kiefer]

Follow-up Comment #15, bug #19352 (project gnustep):

On the cairo mailing list I got the following reply:


   This is already in TODO:
  • cairo_copy_clip() and cairo_copy_clip_flat()
http://lists.freedesktop.org/archives/cairo/2007-April/010520.html


Lets hope they implement it soon.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21446] NSTableView column headers appear misaligned

[Fred Kiefer]

Update of bug #21446 (project gnustep):

  Status:None => Fixed  
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

Should be fixed in SVN. 

This was a result of the missing flipping I corrected some time ago. I am not
sure, if the code now is really correct, but at least the header and the
corner view now put the border onthe same side and if it is still wrong it is
easier to fix now :-)

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21478] Selection issues and invisible view control points with current GNUstep svn

[Fred Kiefer]

Follow-up Comment #2, bug #21478 (project gnustep):

I would like to help out on this problem, but will need some more information
on the internal working of Gorm.

First I would expect that there could be two possible sources for this
problem. One would be just a redraw issue, trickered by Gorm missing some of
the draw method calls from gui. In this case the changes to the draw mechanism
in NSView would be the reason. I noticed that Gorm overrides some internal
NSView methods in GormViewEditor (no idea, if this class is really relevant
here). There displayIfNeededInRectIgnoringOpacity: and 
displayRectIgnoringOpacity: are defined. Now the correct call to override
would be displayRectIgnoringOpacity:inContext: and it would be even better not
to work on that level, but to do what ever is needed for the view in
drawRect:. This would also be save against futher changes of the internal
drawing code, which is to be expected as soon as we start to optimize NSView.

The other potential cause I see is event processing. Here I am really lost,
as I don't have a glue where to look in Gorm. Just the same class
GormViewEditor has a very strange set of event method overrides.

So please give me a hint and I join in to chase this bug.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21478] Selection issues and invisible view control points with current GNUstep svn

[Fred Kiefer]

Follow-up Comment #4, bug #21478 (project gnustep):

Thank you for explaining this. Still I don't see, why most of these methods
just duplicate code from the super implementation, but most likely this is not
important for the current issue.

Did you make any progress? As I said, I would like to help but would need
some pointers, where to look in Gorm. Where are these control points
generated? And where do they get displayed?
Was my last comment of any help or completely off the topic?

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21571] Giant blank app-windows under IceWM

[Fred Kiefer]

Follow-up Comment #1, bug #21571 (project gnustep):

>From the log file I would say that something goes horribly wrong in the way
the window border sizes get computed. The window ends up with a negative size
and at some point this negative number is taken as a huge positive one and
your giant window is requested from X11. This step of course fails.

What we have to do now, is find the place, where the negative number gets
treated as a positive one. This surely is a GNUstep bug.
And we have to find out, why a negative frame size gets reported by the
backend. Here the interaction with the window manager seems to fail. As I
don't think I have IceWM installed, would it be to much to ask you to debug
into this?
The interesting bit is the styleoffsets::: method in XGServerWindow.m.
Here a lot of completely different ways to get the window border sizes are
implemented. Depending on what the WM supports, one of them gets called. It
would be interesting to know, which one this is for IceWM and why it fails.
I promisse to look into the other part of the problem.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[patch #6286] NSBezierPath encode/decode improperly implemented

[Fred Kiefer]

Update of patch #6286 (project gnustep):

Priority:7 - High => 5 - Normal 
 Assigned to:None => FredKiefer 

___

Follow-up Comment #1:

Thank you for the nice patch, but before applying it I would like to
understand some details.

In your error message I can see that an NSKeyedArchiver gets used. As far as
I can see, your patch doesn't implement the missing keyed archiving for
NSBezierPath, so how does it help you?

In my code NSBezierPathElement is always an enumeration, why would the
encoding stuff need the additional hint that it really is an enum? As far as I
can see there is no struct called NSBezierPathElement.

The usage of encodePoint: is surely nice, but in NSCoder it is just defined
as

- (void) encodePoint: (NSPoint)point
{
  [self encodeValueOfObjCType: @encode(NSPoint) at: &point];
}

How should that make any difference? Apart from readability of course. It may
make a difference for keyed encoding though.

It could well be that your patch works around limitations of the keyed
encoding in base. We better should know about these, before we hide them.


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[patch #6286] NSBezierPath encode/decode improperly implemented

[Fred Kiefer]

Follow-up Comment #4, patch #6286 (project gnustep):

First I have to apologize as I didn't find the time to test keyed encoding of
NSBezierPath on the Apple. If we really try to support keyed encoding here, it
should be compatible.

As for your latest problem, I just don't see the issue. What is wrong? To me
it looks like the current code is handling both the cases, LineTo and MoveTo,
correctly. But then I wrote the code in the first place and may not be the
best person to spot a bug there. Ah now I see the problem, in the
initWithCoder: case we are missing a break statement. But the other method
still looks correct to me. In both cases we just need to encode one point and
we share the code for that.

I will fix the missing break as soon as I know what keyed format Apple is
using.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21571] Giant blank app-windows under IceWM

[Fred Kiefer]

Follow-up Comment #4, bug #21571 (project gnustep):

style = 15 means NSTitledWindowMask | NSClosableWindowMask |
NSMiniaturizableWindowMask | NSResizableWindowMask
that is a normal window with a title frame. 
I still need to find the place where we treat these values as signed numbers,
they should all be unsigned and would then be fine.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21681] NSImage drawInRect:fromRect:operation:fraction does not understand NSZeroRect fromRect (does not show up)

[Fred Kiefer]

Update of bug #21681 (project gnustep):

  Status:None => Fixed  
 Assigned to:None => FredKiefer 
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

I submitted a patch to SVN that not only solves this problem, but also limits
the source rectangle to the image bounds. Could you please give it a try?
And thank you for giving GNUstep such a hard testing, we need it.


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21723] Vespucci Window appears on top and cannot be moved to rear...

[Fred Kiefer]

Follow-up Comment #2, bug #21723 (project gnustep):

Which window level is the window using? Is this the correct one and what
behaviour would be expected for that window level?

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21724] Crash when re-opening panel that has been previously closed...

[Fred Kiefer]

Update of bug #21724 (project gnustep):

  Status:None => Confirmed  

___

Follow-up Comment #1:

I had a short look at the Price code and from that I would say it is a Gorm
decoding problem. In the crashing method [PRCConvolve55 showConvolve55:] a
gorm file gets loaded and the window is most likely connected to an instnace
variable. Later, when this variable is reused again after closing the window
the object is gone. Looks like Gorm loading should hold on to objects being
connected.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21766] compile/link problem of WheelPicker on windows

[Fred Kiefer]

Update of bug #21766 (project gnustep):

  Item Group:None => Bug
  Status:None => Fixed  
 Assigned to:None => FredKiefer 
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

Thank you for reporting this problem. It did not show up on Linux. 
I corrected it in SVN, please give the new code a try. As a bonus I added a
nice little feature :-)

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21815] CLIP_MAX_ICONS too small in wconfig.h

[Fred Kiefer]

Follow-up Comment #1, bug #21815 (project gnustep):

Could you please add a hint which application you are talking about? I don't
have a glue about it.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21815] CLIP_MAX_ICONS too small in wconfig.h

[Fred Kiefer]

Update of bug #21815 (project gnustep):

  Status:None => Invalid
 Open/Closed:Open => Declined   

___

Follow-up Comment #3:

>From your comment I take it that this is a bug report on Window Maker. This
isn't the bug tracker for Window Maker. Here you are in the bug system of
GNUstep. Although Window Maker is the official window manager for GNUstep, the
code base is completely separate. 

You should try to report your bug at:
http://www.windowmaker.info/

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21817] problem in XfGlyphExtents + SimpleWebKit

[Fred Kiefer]

Follow-up Comment #1, bug #21817 (project gnustep):

Was this the recursion bug we exchanged mails about? If so, could you please
close the bug report, as that problem was caused by the way simple web kit
inserted horizontal rules.

If not, could you please add some information on how to reproduce this
problem.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21696] [NSText sizeToFit] resizes only to include the first character

[Fred Kiefer]

Follow-up Comment #1, bug #21696 (project gnustep):

I spend some time tracking down this problem and as far as I can tell it is
caused by GSHorizontalTypesetter. There in the method layoutLineNewParagraph:
we get a rectangle for the next set of glyphs and this is already limited by
the text container size. In our case the text container has a size of (1, 15)
and we and up with an almost empty rectangle to layout into.
What happens is that the first character already overlaps and it tries to
break the line. As this fails the rest of the characters as set to invisible
and a wrong rectangle gets computed.

I don't have a glue how to solve this. One way would be to already report the
text container size differently, when it is resizesable. Or use this
information in some other way here. But the whole code looks rather fragile
and I dare not touch it.


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21913] unable to set the system font size

[Fred Kiefer]

Follow-up Comment #1, bug #21913 (project gnustep):

I don't quite understand what you are saying. There are of course plenty of
ways to change the default font size. The setting NSFontSize shoudl for
example affect the system font. But I have no idea whether Gorm will respect
this or if Gorm is requesting a fixed sized font. Or whether the font sizes
used in Gorm are hard coded in the used Gorm files for the interface
elements.
Could you please be a bot more specific what isn't working?

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21912] fonts drawn in the incorrect size

[Fred Kiefer]

Update of bug #21912 (project gnustep):

  Status:None => Duplicate  
  Depends on: => bugs #21625

___

Follow-up Comment #1:

Duplicate of #21625

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21625] Big default font with GNUstep-startup-0.19.0

[Fred Kiefer]

Update of bug #21625 (project gnustep):

Category:  Gui/AppKit => Backend
  Status:None => Confirmed  

___

Follow-up Comment #1:

As this bug report came in the second time now, I should finally comment on
it here:

About half a year ago after an update of my X version I had this problem
myself. It only happens with the xlib backend and I am rather sure that we did
not change anything there ourselves. Most likely X11, or some drivers, now
corrects a problem they had before with point size and pixel size. If I
remember correctly, there was a relation of 1.2 between these two, probably
depending on the dpi of themonitor. It should be fairly easy to change the
relevant font classes in GNUstep to use the now correct size. But a very
likely result will be that fonts will be too small on older systems.

We should first determine, which font systems for the xlib backend are
affected (there are three of them) and then analyse on which specific systems
this now fails. Perhaps it is possible to come ip with some runtime fixup that
works correctly in all cases.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21914] nsfilemanager has problems reporting filesizes on several platforms

[Fred Kiefer]

Follow-up Comment #1, bug #21914 (project gnustep):

Could you please explain the change that you want to see?

GNUstep is currently using f_bavail to determine the available free blocks,
would you like to see this replaced by f_bfree?

Or is that problem that the numbers you get from GNUstep don't match what you
get via df? GNUstep tries to report bytes, perhaps the usage of f_bsize is
rwrong and we should multiply by f_frsize. The documentation is not very clear
on these two values.The old statfs only has f_bsize, which may be the reason
why GNUstep uses this value.

No idea what goes wrong on FreeBSD you should try to get more information
there.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21724] Crash when re-opening panel that has been previously closed...

[Fred Kiefer]

Follow-up Comment #4, bug #21724 (project gnustep):

Could you please report on how to reproduce this problem with your demo
applications? I tried to open the panel, close it, open it again and so on,
but it just keeps on working. Even when pressing that nice button in between
it still reopens the next time.
I was able to reproduce the original problem in Price, perhaps I should also
check that again.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21415] gdnc segfaults on OpenBSD

[Fred Kiefer]

Follow-up Comment #1, bug #21415 (project gnustep):

Is this problem still open? If so, you could try to half the size of all the
arrays in this method. Use 
  unsigned char buf[1024];
  GSStr_t   f;
  unichar   fbuf[512];
and 512 for the following test.

The method initWithFormat:locale:arguments: on NSString (and the similar on
GSString) is really using up a lot of stack space, perhaps that is more
limited for OpenBSD on sparc and so the tools fails there.
If this hack solves the problem, we should think about using the macros
GS_BEGINITEMBUF and GS_ENDITEMBUF from GSPrivate.h here. This would make it
easier to adjust the stack usage for different environments.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21724] Crash when re-opening panel that has been previously closed...

[Fred Kiefer]

Follow-up Comment #6, bug #21724 (project gnustep):

Thank you, now I understand what your test code was for.

I had another go with the Price application and it turns out, it has nothing
to do with the closing of the window. Even without closing that window, just
selecting it again in the menu the applications crashes. I started to debug
this and it seems that the text field pointers get corrupted. Here some debug
output.

Before loading the window:
(gdb) p *self
$1 = {{isa = 0x8071380}, filterWindow = 0x0, matField11 = 0x0,
  matField12 = 0x0, matField13 = 0x0, matField14 = 0x0, matField15 = 0x0,
  matField21 = 0x0, matField22 = 0x0, matField23 = 0x0, matField24 = 0x0,
  matField25 = 0x0, matField31 = 0x0, matField32 = 0x0, matField33 = 0x0,
  matField34 = 0x0, matField35 = 0x0, matField41 = 0x0, matField42 = 0x0,
  matField43 = 0x0, matField44 = 0x0, matField45 = 0x0, matField51 = 0x0,
  matField52 = 0x0, matField53 = 0x0, matField54 = 0x0, matField55 = 0x0,
  scaleField = 0x0, offsetField = 0x0, autoScaleCheck = 0x0,
  convMatrix = {{0, 0, 0, 0, 0}, {0, 0, 0, 0, 0}, {0, 0, 0, 0, 0}, {0, 0,
  0, 0, 0}, {0, 0, 0, 0, 0}}, autoScale = 0 '


___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21912] fonts drawn in the incorrect size

[Fred Kiefer]

Update of bug #21912 (project gnustep):

Category:  Gui/AppKit => Backend

___

Follow-up Comment #2:

No idea how to hide duplicates, at least put it in the correct category.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21696] [NSText sizeToFit] resizes only to include the first character

[Fred Kiefer]

Update of bug #21696 (project gnustep):

  Status:None => Ready For Test 
 Assigned to:None => FredKiefer 
 Open/Closed:Open => In Test

___

Follow-up Comment #2:

I added some code to SVN that should fix this problem. Please test it an
report back.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21695] [NSText sizeToFit] does not resize vertically

[Fred Kiefer]

Update of bug #21695 (project gnustep):

  Status:None => Ready For Test 
 Assigned to:None => FredKiefer 
 Open/Closed:Open => In Test

___

Follow-up Comment #1:

I added some code to SVN that should fix this problem.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21571] Giant blank app-windows under IceWM

[Fred Kiefer]

Update of bug #21571 (project gnustep):

Category:  Gui/AppKit => Backend
 Assigned to:None => FredKiefer 

___

Follow-up Comment #5:

Could you please re-run your application on that window manager with the
parameter  --GNU-Debug=Offset  and report back the results? And after you run
the first GNUstep program could you also report the result of
xprop -root _GNUSTEP_FRAME_OFFSETS

I f you don't get any exta output for the application call you may remove the
stored values via
xprop -root -remove _GNUSTEP_FRAME_OFFSETS 

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #20453] netbsd gui thread safety

[Fred Kiefer]

Follow-up Comment #3, bug #20453 (project gnustep):

I had a close look at the back trace and this looks rather normal to me. A
window gets displayed from the main thread redisplay mechanism. Here I can't
even tell whether a second thread is involved. What I don't see in you back
trace is the reported problem. It cannot be the problem you posted in the
original bug report (Uncaught exception NSInvalidArgumentException, reason:
Tried to add nil to array) as the back trace is already on the X window level
and this is a GNUstep message.
Could it be that you have a second thread running and posted the back trace
from the wrong thread?

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #12151] All windows from an application are present in the Gnome panel (pollution)

[Fred Kiefer]

Follow-up Comment #1, bug #12151 (project gnustep):

Is this still the case? In the mean time we have added code to support the
EWMH, which should result in some of our windows being excluded from the task
bar.
Could you please retest?

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #12051] NSTextView does not implement linkTextAttributes

[Fred Kiefer]

Update of bug #12051 (project gnustep):

  Status:None => Fixed  
 Assigned to:None => FredKiefer 
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

I just remembered that I am now maintainer of gui, so it was easy to decide
that this feature could be added :-)

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #12477] Alt Gr key generates ISO_Level3_Shift keysym

[Fred Kiefer]

Update of bug #12477 (project gnustep):

  Status:None => Wont Fix   
 Assigned to:None => FredKiefer 
 Open/Closed:Open => Declined   

___

Follow-up Comment #3:

I would rather leave this setting to the preferences tool. It is true, even
on my keyboard there isn't a ALT_R key, just the ISO_Level3_Shift key (labeled
Alt Gr).

But if we want to work together with Window Make, we need to leave one ALT
key for that program. So the default settings aren't that bad.

Perhaps we need to state more prominently how to set the key bindings and
what useful values for the  modifier keys are available.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #20304] PNG with alpha channel not properly supported

[Fred Kiefer]

Update of bug #20304 (project gnustep):

  Status:None => Works For Me   
 Assigned to:None => FredKiefer 
 Open/Closed:Open => Declined   

___

Follow-up Comment #2:

I tried to reproduce this problem with a current GNUstep installation and
failed to. I tried with the art, cairo and xlib backend and all seemed to work
more or less correctly. There is an interesting effect with the cario backend,
as there some areas with high transparancy show in white. But this seems to be
a different issue.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #17030] gif crashes gui apps

[Fred Kiefer]

Update of bug #17030 (project gnustep):

  Status:None => Wont Fix   
 Assigned to:None => FredKiefer 
 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Closed as there was no new input from originator for almost one year.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #19100] Application focussing issues

[Fred Kiefer]

Update of bug #19100 (project gnustep):

 Summary: GWorkspace application focussing issues =>
Application focussing issues

___

Follow-up Comment #6:

To make it easier to work on this problem I copied over the last issue from
the original bug report that remains to be be resolved. This can also be seen
in other applications not just GWorkspace:

Situation 1: 
 - Click "Info->Info Panel..." 
 - The Info panel opens but is not focused (er, key window) 
 - Close the info panel without focusing it first 
 - GWorkspace makes another application active 

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #19352] Cairo: bad EPS from NSView_dataWithEPSInsideRect:

[Fred Kiefer]

Follow-up Comment #17, bug #19352 (project gnustep):

I had a look at your patch and it is too low level to keep it in GNUstep. We
would depend upon the internals of cairo. What you could do is lobby for the
inclusion of a similar extension into cairo. Using that code would be fine for
GNUstep.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #16302] gnustep-back-svn 22756 compile error(in Cygwin)

[Fred Kiefer]

Update of bug #16302 (project gnustep):

  Status: In Progress => Ready For Test 
 Assigned to:   fedor => FredKiefer 
 Open/Closed:Open => In Test

___

Follow-up Comment #3:

I just added the suggested patch. Could you please give it a try.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21914] nsfilemanager has problems reporting filesizes on several platforms

[Fred Kiefer]

Update of bug #21914 (project gnustep):

  Status:None => In Progress

___

Follow-up Comment #3:

I added my suggested fix. Could you please give it a try on NetBSD.

As for the FreeBSD case you will need to supply the config.log file, so we
are able to see, which interfaces could be found there.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21914] nsfilemanager has problems reporting filesizes on several platforms

[Fred Kiefer]

Follow-up Comment #5, bug #21914 (project gnustep):

Could you please provide the used test application? Otherwise it is hard to
say for sure, if you are printing out the correct value.
>From you comment I understand that the value you are looking for is the
amount of free space. 
Could you please add an NSLog() statement to the method 
fileSystemAttributesAtPath: to report the used block size? Either this is
wrong, or things go wrong in the calculation. And you need BSD to test both.

Great that at least we only have one problem left, although my patch should
not have affected that difference.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #20453] netbsd gui thread safety

[Fred Kiefer]

Follow-up Comment #5, bug #20453 (project gnustep):

Again a pretty normal back trace without a sign of a problem :-)
What is also needed is the error you get. Only then is it possible to tell,
whether that error is related to the back trace or if there is another thread
involved, which causes the actual problem.

Why should your X system freeze when asking for a text extent? Even when we
have unsupported characters there, it should report an error and not freeze.
Perhaps it would help, if you added a log statement to xGlyphInfo:, but be
warned, this will produce a lot (really a lot) of output.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21979] Possible problem loading Mac OS X Nib

[Fred Kiefer]

Follow-up Comment #5, bug #21979 (project gnustep):

If it is the NSObjectController class that fails, then it is easy to guess
what goes wrong. Somebody added some code to the initWithCoder: method of
NSController, but forgot about the corresponding change to the
encodeWithCoder: method. Just adding these few lines should resolve the
problem in the future. Already stored Gorm files are of course corrupted.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #11557] -hitTest: should check frame rotation.

[Fred Kiefer]

Update of bug #11557 (project gnustep):

 Open/Closed: In Test => Closed 

___

Follow-up Comment #7:

Closed as there was no further feedback for half a year after my last update.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #18412] ugly empty windows popping up

[Fred Kiefer]

Follow-up Comment #4, bug #18412 (project gnustep):

Richard added code to move the test windows outside the screen. (Doesn't work
on KDE)
In most cases this issue should be resolved now.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[patch #6153] Remove XGWM_KDE and XGWM_GNOME support

[Fred Kiefer]

Update of patch #6153 (project gnustep):

 Open/Closed:Open => Closed 

___

Follow-up Comment #2:

Closed as there was no further comment.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[patch #6286] NSBezierPath encode/decode improperly implemented

[Fred Kiefer]

Update of patch #6286 (project gnustep):

  Status:None => Done   
 Open/Closed:Open => Closed 

___

Follow-up Comment #6:

Most of this should be resolved in SVN for some time now. The remaining
difference  @encode(enum NSBezierPathElement) should be down to a compiler
bug, as discussed on the mailing list.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21273] Cairo: combo box menus blacked out

[Fred Kiefer]

Update of bug #21273 (project gnustep):

 Open/Closed: In Test => Closed 


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #20884] NSCell issue

[Fred Kiefer]

Update of bug #20884 (project gnustep):

 Open/Closed: In Test => Closed 


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21912] fonts drawn in the incorrect size

[Fred Kiefer]

Update of bug #21912 (project gnustep):

 Assigned to:None => FredKiefer 
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21625] Big default font with GNUstep-startup-0.19.0

[Fred Kiefer]

Update of bug #21625 (project gnustep):

  Status:   Confirmed => Ready For Test 
 Assigned to:None => FredKiefer 
 Open/Closed:Open => In Test

___

Follow-up Comment #3:

I could confirm this bug on my own system with GSFontAntiAlias set to YES. So
this happens in the GSXftFontInfo class. Here again are two different
branches, one for Fontconfig and one with out that library. I had the problem
in the first case.
I was able to fix the behaviour by switching from FC_SIZE to FC_PIXEL_SIZE.
Now the font appears in about the same size as for the other backends.
It may be that some old version of FC will now show to small fonts. If that
happens we need to add some more checks on the library version. 

Actually GNUstep should do all its drawing in point space, but as this isn't
true for the rest of GNUstep, it should be ok to use pixel space here.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21690] xserver crashes with cairo backend and intel 82815 and XAA

[Fred Kiefer]

Follow-up Comment #1, bug #21690 (project gnustep):

Did you make any progrss on this? I really don't have a glue how to help you
with this issue.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21625] Big default font with GNUstep-startup-0.19.0

[Fred Kiefer]

Follow-up Comment #5, bug #21625 (project gnustep):

No, this patch cannot be in there. The reason you don't see the problem now
is most likely that you are using the art backend not xlib. Or that you have
AA switched off.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21913] unable to set the system font size

[Fred Kiefer]

Follow-up Comment #3, bug #21913 (project gnustep):

I would need a bit more details on where this is happening and what the
expected behaviour should be.
As far as I can tell from the source code, fonts created with a font size of
0 will be treated as being of system size and stored by (non-keyed) encoding
as having system font size. This wont work for NIB files and it also wont work
if a font is explicitly requested to have the system size. Which of these
cases, if any, is it that you are having trouble with?

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #20453] netbsd gui thread safety

[Fred Kiefer]

Follow-up Comment #6, bug #20453 (project gnustep):

Does this problme still persist? If so, could you please add some more
information?



___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22129] GSCUPSPrintInfo may not get default printer if it is networked

[Fred Kiefer]

Update of bug #22129 (project gnustep):

  Status:None => Fixed  
 Assigned to:None => FredKiefer 
 Open/Closed:Open => Closed 

___

Follow-up Comment #1:

Submitted to SVN

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22230] Minimize doesn't seem to work properly

[Fred Kiefer]

Update of bug #22230 (project gnustep):

 Assigned to:None => FredKiefer 

___

Follow-up Comment #1:

We had a discussion about "mini windows" on the GNUstep mailing list just
about a month ago.

Perhaps the following answer helps you as well. At least it help Andreas
Schik who started that thread. If your problem persists, could you please
provide some information about your settings and your window manager?

> > I just tried with Windo Maker 0.92. There mini windows work perfectly 
> > if
> > the GSAppOwnsMiniwindow default is set to NO. When this default is 
> > YES,
> > no mini windows get displayed. Most likely Window Maker is suppressing
> > the mini windows that GNUstep is creating.
> > 
> > With my KDE window manager (what ever it's name is) I get normal 
> > GNUstep
> > mini windows when the default is YES (Only when using the window 
> > menu!)
> > and no mini windows when the default is NO.
> > 
> > As your Window Maker seems to behave different from mine, I would 
> > expect
> > that you have a specific configuration for your Window Maker that 
> > needs
> > to be corrected.
OK, thanks for the hint. I played around with WMaker's mini window
settings and found that the menu works if I switch on 'omnipresent
mini windows'. As i use only one workspace I ignored this setting so
far. But still mini windows work only if GSAppOwnsMiniwindow is set to
NO ( as you descrbe above).
What is the reason behind GSAppOwnsMiniwindow anyway? What do I
achieve if I set it to YES?


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22247] Pre-multiplied alpha values for bitmaps

[Fred Kiefer]

URL:
  

 Summary: Pre-multiplied alpha values for bitmaps
 Project: GNUstep
Submitted by: FredKiefer
Submitted on: Donnerstag 07.02.2008 um 08:57
Category: Backend
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: FredKiefer
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

For bitmap data with an alpha chanle there are two ways to store the colour
values for each pixel, either the basic value (for example r 255, g 0, b 0, a
128 for a half transparent red) or pre-multiplied with the alpha value (in our
case this gives r 128, g 0, b 0, a 128). The later is easier for correct
colour operations and is the format that the specification requires.

The different GNUstep backends expect different sorts of bitmap data. Xlib
and cairo expect pre-multiplied alpha whereas art expects non-pre-multiplied
values. This leads to different results when one or the other format is given.

Our TIFF loader returns either format, depending on the stored TIFF data, the
PNG loader always returns non-pre-multiplied bitmaps. That way some TIFFs and
all PNG with alpha chanel get displayed wrongly in the cairo and xlib backend
and soem TIFFs in the art backend.
I did not look into the other loadable bitmap formats nor into the winlib
backend.

To resolve this we first need to stored the format with each loaded and
generated bitmap, this is now possible with a 10.4 extension of NSBitmapRep
(NSAlphaNonpremultipliedBitmapFormat). Next we will need to extend the bitmap
value conversions to handle this case (-colorAtX:Y:, -setColor:atX:Y:) and
perhaps write a generic converter.
The final step will then be to implement the correct handling of all possible
formats in the backends. Here I see the biggest problem in the art backend.
For the other backends I would just suggest to convert all formats into the
pre-multiplied form, but for art it would be nice to implement the blit code
to work directly with the pre-multiplied values.







___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22246] problem with key value observation

[Fred Kiefer]

URL:
  

 Summary: problem with key value observation
 Project: GNUstep
Submitted by: FredKiefer
Submitted on: Donnerstag 07.02.2008 um 08:42
Category: Base/Foundation
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any

___

Details:

In gui I use KVO to implement KVB. The last change I made on that some time
ago should allow a back chanel from the user inteface elements to the bound
controller. Now this bit is failing. For a check box I get a strange effect.
When I switch this checkbox on by clicking on it, it is shown on very shortly
but gets switched off again immediatly. Debugging this showed that the call to
setValue:For: on the controller results in three changes reported back to the
user interface. One from the actual setSomething: method in the controller
class (which is fine), one from takeValue:For: (which could be switched off,
as far as I understand the code) and one from setValue:For:. 
Now there should be a way that the KVO mechanism is able to tell that it
already send the notification for a change and use the underlying methods of
the base class to change the value, not the cooked up methods from the special
class. But this isn't the real problem, what makes it worse for me is that the
set value changes. This seems to happen in the takeValue:For: call, as I get
the correct value once and then twice the wrong one.
It is this later behaviour that I don't understand. Anybody with an idea,
what may be happening?




___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22247] Pre-multiplied alpha values for bitmaps

[Fred Kiefer]

Update of bug #22247 (project gnustep):

  Status:None => In Progress

___

Follow-up Comment #1:

The first part of this change, mostly in gui, is done now. For TIFF and PNG
images we now set the format correctly.
For the art backend I added a hack to convert all bitmaps to
non-pre-multiplied format before using them. We could add a similar hack to
the other backends to change all bitmaps to the pre-multiplied form. Or even
better change all bitmaps when we create them to this form.
Currently it still seems better to me to pass the image format down to the
drawing code and let that handle all different formats, or use a conversion.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21913] unable to set the system font size

[Fred Kiefer]

Follow-up Comment #5, bug #21913 (project gnustep):

Could you give me a list of user elements that should respect the font size
settings but don't do so? With that I would be able to look into some of the
specific cases and find out if the application code is wrong (Using explicit
size) or if some GNUstep gui code fails (perhaps also uses explicit font
size).

To make this task feasible it will be needed that you point me to the source
or Gorm file where the user element is created. It is to hard to dig through a
huge application like Gorm or GWorkspace to find the place where a specific
font gets created.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22278] Nib reading issues with System fonts and button borders

[Fred Kiefer]

Update of bug #22278 (project gnustep):

  Status:None => In Progress

___

Follow-up Comment #2:

I added a fallback in NSFont to handle requests for LucidaGrande that fail
due to a missing font, as requests for the default font. Hope this helps with
your problem.

Could you please describe which special cases are still open?

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22261] Window turns black during resizing on Win32/MINGW when GSBackHandlesWindowDecorations==TRUE

[Fred Kiefer]

Follow-up Comment #1, bug #22261 (project gnustep):

This is a great patch and it is even more important that somebody takes up
cleaning up our MS Windows code.

That said, I am not sure, whether this is the right answer to the general
problem. All of our backends have, or or less redrawing problems while
resizing the window.
For Windows this could be increased, as resizing is handled on the WM_SIZE
and not WM_SIZING level, but I am not sure about that.

Perhaps we could come up with a general concept, when and where redrawing
should be triggered during the resizing. There are some new methods on
NSWindow that could help with that, again I am not that sure.



___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22261] Window turns black during resizing on Win32/MINGW when GSBackHandlesWindowDecorations==TRUE

[Fred Kiefer]

Follow-up Comment #3, bug #22261 (project gnustep):

The redrawing while resizing problems on X11 are just the same as on Windows.
You sometimes get a black window when the application is to busy to do a
redraw while resizing.

What happens when a window gets resized is that the backend will be notified
from the window system about the new size. It then sends an
GSAppKitWindowResized event to the front end (which only happans in some cases
for Windows) and NSWindow _processResizeEvent calls
setWindowdevice:forContext:, which takes over the actual resizing and the
adjusting of the drawing environment. It may well be that this method also
should do a needsDisplay:, but I am not sure.
The setWindowdevice:forContext: method is the place where I would expect
resizeBackingStoreFor: to be called, but currently this is different for the
windows backend (Why?).
Now all this strange behaviour was there before your patch, but perhaps your
patch could look different with it being resolved.

The other part is where and how we want redraws to happen. In GNUstep
(almost) all redraws should come from the _handleAutodisplay method on
NSWindow. This does a displayIfNeeded followed by a flushWindowIfNeeded. This
is a drawing mechanism that does not go via the standard Windows WM_PAINT
route. WM_PAINT should only apply when a part of a window gets exposed by
window movement or resizing. Your mechanism to deal with that case may be the
correct one, I am just not sure, it doesn't have any side effects for the
other cases. Maybe I just need to look at the code a bit longer.



___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22261] Window turns black during resizing on Win32/MINGW when GSBackHandlesWindowDecorations==TRUE

[Fred Kiefer]

Update of bug #22261 (project gnustep):

  Status:None => Fixed  
 Assigned to:None => FredKiefer 
 Open/Closed:Open => Closed 

___

Follow-up Comment #5:

I commited your patch and also cleaned up the window backend code. Now it is
at least basically maintainable.

The same open issues remain. I am still not convinced that your fix is the
best way to address the resize problem. But the search for the best solution
can wait now.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #21571] Giant blank app-windows under IceWM

[Fred Kiefer]

Follow-up Comment #8, bug #21571 (project gnustep):

Thank you for your in depth analysis of this problem. To me it seems that
there are multiple issues that come together. I would say that the code in the
loop that does the l, t, r, b computiation is wrong. It should only take the
wattr.x and wattr.y values into account for the next lower window, not for the
current one. These values give the postion of the window relative to its
parent, so we should only use them, when the width, heigth also refer to the
parent. 
But this still does not explain your issue. For you it seems as it the loop
is stopped after the first parent, although we are rather sure there should be
at least two. Why does this happen?

I hope to find time to play with this code over the next few days, still I
would need somebody to test any change, as I cannot reproduce the problem.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22278] Nib reading issues with System fonts and button borders

[Fred Kiefer]

Follow-up Comment #4, bug #22278 (project gnustep):

Oh yes, the warnign message will stay the same. This gets produced on a lower
level, in the backend. And of course this change wont help you to get any
other font displayed that you did not install :-)

I am not sure, what you are expecting. What is it that GNUstep should be
doing? When a font isn't installed we need to use a proper replacement, as you
only have one font installed there isn't much choice for GNUstep, what it
should be doing.

The patch I added should help in the case, where in the NIB file a bold
system font was saved on a Mac. In that case the available bold system font
will be chosen. 

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #13509] FFI problem on Gentoo

[Fred Kiefer]

Update of bug #13509 (project gnustep):

  Status:None => Wont Fix   
 Open/Closed:Open => In Test

___

Follow-up Comment #7:

There now is a separate supported version of libffi outside of gcc:

http://sourceware.org/libffi/

For this reason I think we may as well close this as a GNUstep bug report.

I am currently not using ffi, but will switch over to it as soon as pacakges
are available for SuSE Linux. It would be great if somebody could check this
new release in the meantime.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #3414] Font size inconsistency

[Fred Kiefer]

Follow-up Comment #5, bug #3414 (project gnustep):

No, sad enough that change was actually the other way around. I had to change
a place where we were using a point size interface to request a font into one
using pixel size, to get it to work properly with the rest of GNUstep.

You could say this way one step back, as far as this specific bug report is
concerned.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22409] Images displaying incorrectly in some cases....

[Fred Kiefer]

Update of bug #22409 (project gnustep):

  Status:None => In Progress
 Assigned to:None => FredKiefer 

___

Follow-up Comment #1:

It really would help if you supplied some information on which backend is
showing this behaviour. Most likely it will be art our default backend and
there has been one significant change in this area.

As I explain in great detail in bug report #22247, the whole bitmap image
handling in GNUstep was screwed up. Some backends use pre-multiplied alpha and
others don't and for the loaded images the same holds true. What I changed was
the the art backend now turns all displayed bitmaps to non-pre-multiplied
before drawing, as this is the format it understands.
It is quite likely that now images look different. On the other hand it is
also possible that the code in [NSBitmapImageRep _unpremultiply gets some
cases wrong. I will look into this specific issue right now. Is it correct
that this is FileProject.tiff from projectcenter/Images?

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22409] Images displaying incorrectly in some cases....

[Fred Kiefer]

Update of bug #22409 (project gnustep):

  Status: In Progress => Ready For Test 
 Open/Closed:Open => In Test

___

Follow-up Comment #2:

The images where not flaged as having a changed format. That way the image
was unpremultiplied over and over again resulting in a black area. This should
be fixed in SVN now.

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22410] Apps segfault on a second display

[Fred Kiefer]

Follow-up Comment #1, bug #22410 (project gnustep):

This error is only possible if either window or context is no valid pointer.
As window gest used imidiatly before that line, it must be context, which is
invalid, probably NULL.

This could only happen, when the screen cannot be initialized, so there
wouldn't be any screen context for that default screen. I am wondering how the
existence ofthe second screen may have any influence here. But I have never
tried GNUstep i a multi screen environment.

Was there any warning message before the error occured?

___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep

[bug #22410] Apps segfault on a second display

[Fred Kiefer]

Follow-up Comment #2, bug #22410 (project gnustep):

Just one more tip to get more output. Could you please restart the failing
application with the option --GNU-Debug=dflt


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/



___
Bug-gnustep mailing list
Bug-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-gnustep