Testing for drawing fixes r30523

[Quentin Mathé]

Hi,

I just committed a patch I have been working on for a while. See bug  
report https://savannah.gnu.org/bugs/?27782


This should solve various differences between GNUstep vs Cocoa image  
drawing when Cairo is used, especially with -[NSImage  
drawInRect:fromRect:operation:fraction:] or similar.


For the Cairo backend, this method should now give the same result  
than Cocoa when the destination is flipped, rotated or scaled. The  
scaling between the inRect and the fromRect should also work  
correctly. Various border cases such as passing NSZeroRect are now  
handled in a way that matches Cocoa.
The performance should also be much better when you draw a small  
source rect from a big image, since we only manipulate the source rect  
area rather than the whole image now. We also do not create an  
intermediate image to apply the graphics context transform, we just  
delegate that to Cairo, so this should improve performance a bit too.


Cairo also had various issues with -compositeGStateXXX and - 
DPSimageXXX. This means NSImage composite/dissolve methods now behave  
correctly, NSCopyBits too and -[NSView scrollRect:by:] should work in  
non-flipped coordinates unlike previously.


The Cairo backend unlike other backends should now match the Cocoa  
image drawing behavior exactly. This should be visible if you play  
with NSAffineTransform a lot. For example, in a flipped view, concat a  
rotation, a scaling and a manual flip transform, then draw an image  
with by scaling it with inRect and fromRect.


Art, Xlib and Winlib backends shouldn't have changed much since they  
still use the old code path. This code path is much more complex than  
the Cairo code path that delegates as much as possible to the backend  
rather than trying to handle things like rotation on the Gui side.


I tested Cairo, Art and Xlib, they work fine for me with GSTest, Gorm  
and various Étoilé applications. I haven't tested the Winlib backend,  
so I'm interested to know if it still works correctly.
I'll commit the test application I have been using to compare Cocoa vs  
GNUstep behavior soon.


Although I tried to simplify the code as much as possible, there are  
still some cleaning to do and also things to be worked out. e.g.  
NSCopyBits doesn't behave the same on GNUstep and Cocoa when you give  
it a view gstate.


Cheers,
Quentin.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Doug Simons]

Hi,This change has broken some things on Windows. Here is a screenshot from our application showing the problem, with an image displayed in a tableView (the table here contains only one row):When I roll back this change, it displays as it should:It's hard to tell from this particular image, but the image itself is not flipped, just displaced. Hopefully that's enough for you to tell what's going on. If you need additional information please let me know.Doug












On Jun 1, 2010, at 6:00 AM, Quentin Mathé wrote:Hi,I just committed a patch I have been working on for a while. See bug report https://savannah.gnu.org/bugs/?27782This should solve various differences between GNUstep vs Cocoa image drawing when Cairo is used, especially with -[NSImage drawInRect:fromRect:operation:fraction:] or similar.For the Cairo backend, this method should now give the same result than Cocoa when the destination is flipped, rotated or scaled. The scaling between the inRect and the fromRect should also work correctly. Various border cases such as passing NSZeroRect are now handled in a way that matches Cocoa.The performance should also be much better when you draw a small source rect from a big image, since we only manipulate the source rect area rather than the whole image now. We also do not create an intermediate image to apply the graphics context transform, we just delegate that to Cairo, so this should improve performance a bit too.Cairo also had various issues with -compositeGStateXXX and -DPSimageXXX. This means NSImage composite/dissolve methods now behave correctly, NSCopyBits too and -[NSView scrollRect:by:] should work in non-flipped coordinates unlike previously.The Cairo backend unlike other backends should now match the Cocoa image drawing behavior exactly. This should be visible if you play with NSAffineTransform a lot. For example, in a flipped view, concat a rotation, a scaling and a manual flip transform, then draw an image with by scaling it with inRect and fromRect.Art, Xlib and Winlib backends shouldn't have changed much since they still use the old code path. This code path is much more complex than the Cairo code path that delegates as much as possible to the backend rather than trying to handle things like rotation on the Gui side.I tested Cairo, Art and Xlib, they work fine for me with GSTest, Gorm and various Étoilé applications. I haven't tested the Winlib backend, so I'm interested to know if it still works correctly.I'll commit the test application I have been using to compare Cocoa vs GNUstep behavior soon.Although I tried to simplify the code as much as possible, there are still some cleaning to do and also things to be worked out. e.g. NSCopyBits doesn't behave the same on GNUstep and Cocoa when you give it a view gstate.Cheers,Quentin.___Gnustep-dev mailing listGnustep-dev@gnu.orghttp://lists.gnu.org/mailman/listinfo/gnustep-dev___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Quentin Mathé]

Hi Doug,

Le 2 juin 2010 à 21:36, Doug Simons a écrit :

This change has broken some things on Windows. Here is a screenshot  
from our application showing the problem, with an image displayed in  
a tableView (the table here contains only one row):




When I roll back this change, it displays as it should:



It's hard to tell from this particular image, but the image itself  
is not flipped, just displaced. Hopefully that's enough for you to  
tell what's going on. If you need additional information please let  
me know.


I think the backend is trying to compensate/revert an extra flipping  
previously done in Gui.
The code where the problem is located is -[Win32GState  
compositeGState:fromRect:toPoint:op:fraction:] pasted below.


The implementation looks similar to the old Cairo implementation, so  
the best way is probably to rewrite it in a similar way. That means I  
have to set up Windows somewhere since it's hard to get the  
implementation right. I don't have time today, but tomorrow I'll try  
to get a working GNUstep install on Windows to work on it.


By the way, does the scrolling still work on Windows?


if (viewIsFlipped && (self
 != source))
{
  destPoint.y -= sourceRect.size.height;
}


You can try to remove this part since the backend shouldn't need it  
now. But I I don't think it's enough to fix it.



  destRect.origin = destPoint;
  destRect.size = sourceRect.size;
  [ctm boundingRectFor: destRect result: &destRect];


The transform should be applied to destPoint only here.


  rectTo = GSWindowRectToMS(
self
, destRect);
  x = rectTo.left;
  y = rectTo.bottom - sourceRect.size.height;

  {
NSRect newRect;

[source->ctm boundingRectFor: sourceRect result: &newRect];
rectFrom = GSWindowRectToMS(source, newRect);
y += (sourceRect.size.height - newRect.size.height);
// adjust location for scaled source


The line before the last one looks dubious to me. To get it working  
properly in all cases (rotation, scaling, flipping etc.), I had to  
rewrite the Cairo backend to use a more complex check.


Thanks for feedback,
Quentin.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Doug Simons]

Quentin, thanks for working on this.

As a simple test, I tried commenting out these lines:
> if (viewIsFlipped && (self
> != source))
>{
>  destPoint.y -= sourceRect.size.height;
>}

That fixed the display of the image in the tableView, but introduced the same 
problem for all of the images of items in my toolbar: they were all shifted 
down and drawn with their tops in the same place as the item titles. So clearly 
a more sophisticated change is needed.

I tried a couple of other things without success, but it would take some time 
for me to wrap my head around what's going on here and really understand it, so 
at this point I'm just poking at things in the dark.

If you can get this running on Windows and make whatever adjustments it needs 
to work with your other recent changes, that would be greatly appreciated. 
Thanks!

Doug


On Jun 3, 2010, at 4:46 AM, Quentin Mathé wrote:

> Hi Doug,
> 
> Le 2 juin 2010 à 21:36, Doug Simons a écrit :
> 
>> This change has broken some things on Windows. Here is a screenshot from our 
>> application showing the problem, with an image displayed in a tableView (the 
>> table here contains only one row):
>> 
>> 
>> 
>> When I roll back this change, it displays as it should:
>> 
>> 
>> 
>> It's hard to tell from this particular image, but the image itself is not 
>> flipped, just displaced. Hopefully that's enough for you to tell what's 
>> going on. If you need additional information please let me know.
> 
> I think the backend is trying to compensate/revert an extra flipping 
> previously done in Gui.
> The code where the problem is located is -[Win32GState 
> compositeGState:fromRect:toPoint:op:fraction:] pasted below.
> 
> The implementation looks similar to the old Cairo implementation, so the best 
> way is probably to rewrite it in a similar way. That means I have to set up 
> Windows somewhere since it's hard to get the implementation right. I don't 
> have time today, but tomorrow I'll try to get a working GNUstep install on 
> Windows to work on it.
> 
> By the way, does the scrolling still work on Windows?
> 
>> if (viewIsFlipped && (self
>> != source))
>>{
>>  destPoint.y -= sourceRect.size.height;
>>}
> 
> You can try to remove this part since the backend shouldn't need it now. But 
> I I don't think it's enough to fix it.
> 
>>  destRect.origin = destPoint;
>>  destRect.size = sourceRect.size;
>>  [ctm boundingRectFor: destRect result: &destRect];
> 
> The transform should be applied to destPoint only here.
> 
>>  rectTo = GSWindowRectToMS(
>> self
>> , destRect);
>>  x = rectTo.left;
>>  y = rectTo.bottom - sourceRect.size.height;
>> 
>>  {
>>NSRect newRect;
>> 
>>[source->ctm boundingRectFor: sourceRect result: &newRect];
>>rectFrom = GSWindowRectToMS(source, newRect);
>>y += (sourceRect.size.height - newRect.size.height);
>> // adjust location for scaled source
> 
> The line before the last one looks dubious to me. To get it working properly 
> in all cases (rotation, scaling, flipping etc.), I had to rewrite the Cairo 
> backend to use a more complex check.
> 
> Thanks for feedback,
> Quentin.
> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
> 

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Doug Simons]

Quentin,

Did you have a chance to try this on Windows yet? We are stuck on moving 
forward with  any new updates in gui or back until this is resolved, which is 
not good.

Thanks,

Doug

On Jun 3, 2010, at 9:41 AM, Doug Simons wrote:

> Quentin, thanks for working on this.
> 
> As a simple test, I tried commenting out these lines:
>> if (viewIsFlipped && (self
>> != source))
>>{
>>  destPoint.y -= sourceRect.size.height;
>>}
> 
> That fixed the display of the image in the tableView, but introduced the same 
> problem for all of the images of items in my toolbar: they were all shifted 
> down and drawn with their tops in the same place as the item titles. So 
> clearly a more sophisticated change is needed.
> 
> I tried a couple of other things without success, but it would take some time 
> for me to wrap my head around what's going on here and really understand it, 
> so at this point I'm just poking at things in the dark.
> 
> If you can get this running on Windows and make whatever adjustments it needs 
> to work with your other recent changes, that would be greatly appreciated. 
> Thanks!
> 
> Doug
> 
> 
> On Jun 3, 2010, at 4:46 AM, Quentin Mathé wrote:
> 
>> Hi Doug,
>> 
>> Le 2 juin 2010 à 21:36, Doug Simons a écrit :
>> 
>>> This change has broken some things on Windows. Here is a screenshot from 
>>> our application showing the problem, with an image displayed in a tableView 
>>> (the table here contains only one row):
>>> 
>>> 
>>> 
>>> When I roll back this change, it displays as it should:
>>> 
>>> 
>>> 
>>> It's hard to tell from this particular image, but the image itself is not 
>>> flipped, just displaced. Hopefully that's enough for you to tell what's 
>>> going on. If you need additional information please let me know.
>> 
>> I think the backend is trying to compensate/revert an extra flipping 
>> previously done in Gui.
>> The code where the problem is located is -[Win32GState 
>> compositeGState:fromRect:toPoint:op:fraction:] pasted below.
>> 
>> The implementation looks similar to the old Cairo implementation, so the 
>> best way is probably to rewrite it in a similar way. That means I have to 
>> set up Windows somewhere since it's hard to get the implementation right. I 
>> don't have time today, but tomorrow I'll try to get a working GNUstep 
>> install on Windows to work on it.
>> 
>> By the way, does the scrolling still work on Windows?
>> 
>>> if (viewIsFlipped && (self
>>> != source))
>>>{
>>>  destPoint.y -= sourceRect.size.height;
>>>}
>> 
>> You can try to remove this part since the backend shouldn't need it now. But 
>> I I don't think it's enough to fix it.
>> 
>>>  destRect.origin = destPoint;
>>>  destRect.size = sourceRect.size;
>>>  [ctm boundingRectFor: destRect result: &destRect];
>> 
>> The transform should be applied to destPoint only here.
>> 
>>>  rectTo = GSWindowRectToMS(
>>> self
>>> , destRect);
>>>  x = rectTo.left;
>>>  y = rectTo.bottom - sourceRect.size.height;
>>> 
>>>  {
>>>NSRect newRect;
>>> 
>>>[source->ctm boundingRectFor: sourceRect result: &newRect];
>>>rectFrom = GSWindowRectToMS(source, newRect);
>>>y += (sourceRect.size.height - newRect.size.height);
>>> // adjust location for scaled source
>> 
>> The line before the last one looks dubious to me. To get it working properly 
>> in all cases (rotation, scaling, flipping etc.), I had to rewrite the Cairo 
>> backend to use a more complex check.
>> 
>> Thanks for feedback,
>> Quentin.
>> 
>> 
>> ___
>> Gnustep-dev mailing list
>> Gnustep-dev@gnu.org
>> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> http://lists.gnu.org/mailman/listinfo/gnustep-dev

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Wolfgang Lux]

Quentin Mathé wrote:

I just committed a patch I have been working on for a while. See  
bug report https://savannah.gnu.org/bugs/?27782


It looks like your changes have inadvertently introduced a new bug.  
Clicking on the overflow menu of a toolbar now causes a crash in  
every application. For instance, the following traceback was produced  
with ToolbarExample after shrinking it horizontally so much that an  
overflow menu item appears and then clicking that item.


Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x0004
0x0300b894 in cairo_get_target ()
(gdb) bt
#0  0x0300b894 in cairo_get_target ()
#1  0x0345ec84 in -[CairoGState  
compositeGState:fromRect:toPoint:op:fraction:] (self=0x33d9208,  
_cmd=0x34714b0, source=0x330b998, srcRect={origin = {x = 0, y = 0},  
size = {width = 20, height = 20}}, destPoint={x = 4, y = 41},  
op=NSCompositeSourceOver, delta=1) at CairoGState.m:1273
#2  0x0340cb00 in -[GSContext(Ops)  
GScomposite:toPoint:fromRect:operation:fraction:] (self=0x33d79f8,  
_cmd=0x1439d88, gstateNum=12, aPoint={x = 4, y = 41}, srcRect={origin  
= {x = 0, y = 0}, size = {width = 20, height = 20}},  
op=NSCompositeSourceOver, delta=1) at GSContext.m:817
#3  0x0114f4e4 in -[NSImage  
compositeToPoint:fromRect:operation:fraction:] (self=0x3761c88,  
_cmd=0x1439d58, aPoint={x = 4, y = 41}, srcRect={origin = {x = 0, y =  
0}, size = {width = 20, height = 20}}, op=NSCompositeSourceOver,  
delta=1) at NSImage.m:864
#4  0x0114efa4 in -[NSImage compositeToPoint:fromRect:operation:]  
(self=0x3761c88, _cmd=0x1439d50, aPoint={x = 4, y = 41}, aRect= 
{origin = {x = 0, y = 0}, size = {width = 20, height = 20}},  
op=NSCompositeSourceOver) at NSImage.m:815
#5  0x0114ee70 in -[NSImage compositeToPoint:operation:]  
(self=0x3761c88, _cmd=0x145472c, aPoint={x = 4, y = 41},  
op=NSCompositeSourceOver) at NSImage.m:808

#6  0x000e85d4 in ffi_call_DARWIN ()
#7  0x000e7c4c in ffi_call (cif=0x3309200, fn=0x114ed34 <-[NSImage  
compositeToPoint:operation:]>, rvalue=0x3320fd4, avalue=0x3309238) at  
src/powerpc/ffi_darwin.c:457
#8  0x0214e0bc in GSFFIInvokeWithTargetAndImp (inv=0x3320fa8,  
anObject=0x3761c88, imp=0x114ed34 <-[NSImage  
compositeToPoint:operation:]>) at GSFFIInvocation.m:396
#9  0x0214e644 in -[GSFFIInvocation invokeWithTarget:]  
(self=0x3320fa8, _cmd=0x1453cec, anObject=0x3761c88) at  
GSFFIInvocation.m:470
#10 0x01330be8 in -[GSThemeProxy forwardInvocation:] (self=0x3761388,  
_cmd=0x21fc8f4, anInvocation=0x3320fa8) at GSTheme.m:1332
#11 0x0214f0e4 in GSFFIInvocationCallback (cif=0x3309200,  
retp=0xbfffdae0, args=0xbfffd9c0, user=0x3309200) at  
GSFFIInvocation.m:636
#12 0x000e84dc in ffi_closure_helper_DARWIN (closure=0x704000,  
rvalue=0xbfffdae0, pgr=0xbfffdb1c, pfr=0xbfffda78) at src/powerpc/ 
ffi_darwin.c:796

#13 0x000e86b4 in ffi_closure_ASM ()
#14 0x01336c60 in -[GSTheme(Drawing)  
drawImage:inButtonCell:withFrame:position:] (self=0x3738e88,  
_cmd=0x142ff8c, image=0x3761388, cell=0x3761428, aRect={origin = {x =  
0, y = 0}, size = {width = 28, height = 62}}, position={x = 4, y =  
41}) at GSThemeDrawing.m:765
#15 0x01094ba4 in -[NSButtonCell drawImage:withFrame:inView:]  
(self=0x3761428, _cmd=0x142ffec, imageToDisplay=0x3761388, cellFrame= 
{origin = {x = 0, y = 0}, size = {width = 28, height = 62}},  
controlView=0x3729108) at NSButtonCell.m:957
#16 0x01095c74 in -[NSButtonCell drawInteriorWithFrame:inView:]  
(self=0x3761428, _cmd=0x1430c0c, cellFrame={origin = {x = 0, y = 0},  
size = {width = 28, height = 62}}, controlView=0x3729108) at  
NSButtonCell.m:1249
#17 0x010a4df4 in -[NSCell drawWithFrame:inView:] (self=0x3761428,  
_cmd=0x142a578, cellFrame={origin = {x = 0, y = 0}, size = {width =  
28, height = 62}}, controlView=0x3729108) at NSCell.m:2055
#18 0x01010060 in -[NSActionCell drawWithFrame:inView:]  
(self=0x3761428, _cmd=0x1430c2c, cellFrame={origin = {x = 0, y = 0},  
size = {width = 28, height = 62}}, controlView=0x3729108) at  
NSActionCell.m:344
#19 0x010a5160 in -[NSCell highlight:withFrame:inView:]  
(self=0x3761428, _cmd=0x142fc00, lit=1 '\001', cellFrame={origin = {x  
= 0, y = 0}, size = {width = 28, height = 62}},  
controlView=0x3729108) at NSCell.m:2107
#20 0x0108f80c in -[NSButton highlight:] (self=0x3729108,  
_cmd=0x14596fc, flag=1 '\001') at NSButton.m:392
#21 0x013be7fc in -[GSToolbarClippedItemsButton mouseDown:]  
(self=0x3729108, _cmd=0x144d960, event=0x318d748) at GSToolbarView.m:206
#22 0x012e3914 in -[NSWindow sendEvent:] (self=0x3322458,  
_cmd=0x142c6d0, theEvent=0x318d748) at NSWindow.m:3837
#23 0x0103e7bc in -[NSApplication sendEvent:] (self=0x3335478,  
_cmd=0x142c600, theEvent=0x318d748) at NSApplication.m:2282
#24 0x0103c03c in -[NSApplication run] (self=0x3335478,  
_cmd=0x142a3b8) at NSApplication.m:1662
#25 0x01009460 in NSApplicationMain (argc=1, argv=0xbfffe650) at  
Functions.m:89
#26 0x2aac in gnustep_base_user_main (argc=1, argv=0xbfffe650) at  
main.m:13
#27 0

Re: Testing for drawing fixes r30523

[Fred Kiefer]

Am 01.06.2010 14:00, schrieb Quentin Mathé:
> I just committed a patch I have been working on for a while. See bug
> report https://savannah.gnu.org/bugs/?27782

I just tested this patch with the cairo backend and completely
recompiled GNUstep from SVN. Scrolling in any NSTableView seems to be
broken. Open, for example, the memory panel in GSTest (or any other
GNUstep application) by clicking on the icon in the info panel. Now try
to scroll down by using the scroll arrows. The main contents of the
table view isn't copies. Only the newly scrolled in lines will get
drawn. Similar things happen when trying to scroll up, left or right.

I would say the scrolling in flipped views is broken. I will go ahead
and test with the art and xlib backend and report the behaviour there.

Fred

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Fred Kiefer]

Am 06.06.2010 20:27, schrieb Fred Kiefer:
> Am 01.06.2010 14:00, schrieb Quentin Mathé:
>> I just committed a patch I have been working on for a while. See bug
>> report https://savannah.gnu.org/bugs/?27782
> 
> I just tested this patch with the cairo backend and completely
> recompiled GNUstep from SVN. Scrolling in any NSTableView seems to be
> broken. Open, for example, the memory panel in GSTest (or any other
> GNUstep application) by clicking on the icon in the info panel. Now try
> to scroll down by using the scroll arrows. The main contents of the
> table view isn't copies. Only the newly scrolled in lines will get
> drawn. Similar things happen when trying to scroll up, left or right.
> 
> I would say the scrolling in flipped views is broken. I will go ahead
> and test with the art and xlib backend and report the behaviour there.

Sorry, forget about this bug report. While switching the backend I
noticed that I had still used an old cairo backend that didn't include
all the new changes. With the correct new backing scrolling works even
in a table view.

Fred

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Fred Kiefer]

Am 06.06.2010 19:39, schrieb Wolfgang Lux:
> Quentin Mathé wrote:
> 
>> I just committed a patch I have been working on for a while. See bug
>> report https://savannah.gnu.org/bugs/?27782
> 
> It looks like your changes have inadvertently introduced a new bug.
> Clicking on the overflow menu of a toolbar now causes a crash in every
> application. For instance, the following traceback was produced with
> ToolbarExample after shrinking it horizontally so much that an overflow
> menu item appears and then clicking that item.
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_PROTECTION_FAILURE at address: 0x0004
> 0x0300b894 in cairo_get_target ()
> (gdb) bt
> #0  0x0300b894 in cairo_get_target ()
> #1  0x0345ec84 in -[CairoGState
> compositeGState:fromRect:toPoint:op:fraction:] (self=0x33d9208,
> _cmd=0x34714b0, source=0x330b998, srcRect={origin = {x = 0, y = 0}, size
> = {width = 20, height = 20}}, destPoint={x = 4, y = 41},
> op=NSCompositeSourceOver, delta=1) at CairoGState.m:1273

Should be fixed in SVN now.

Fred

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Quentin Mathé]

Le 5 juin 2010 à 00:31, Doug Simons a écrit :

Did you have a chance to try this on Windows yet? We are stuck on  
moving forward with  any new updates in gui or back until this is  
resolved, which is not good.


I haven't yet, I was away for the week-end. I'm currently finishing to  
install GNUstep on Windows. Once I get the example running, I'll solve  
the issue asap.


Quentin.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Doug Simons]

Thanks Quentin, we appreciate it!

For the sake of tracking this issue, I've opened bug #30069 in the bug system.

Doug

On Jun 7, 2010, at 3:35 AM, Quentin Mathé wrote:

> Le 5 juin 2010 à 00:31, Doug Simons a écrit :
> 
>> Did you have a chance to try this on Windows yet? We are stuck on moving 
>> forward with  any new updates in gui or back until this is resolved, which 
>> is not good.
> 
> I haven't yet, I was away for the week-end. I'm currently finishing to 
> install GNUstep on Windows. Once I get the example running, I'll solve the 
> issue asap.
> 
> Quentin.

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Riccardo Mottola]

Hi,


Did you have a chance to try this on Windows yet? We are stuck on 
moving forward with  any new updates in gui or back until this is 
resolved, which is not good.


I haven't yet, I was away for the week-end. I'm currently finishing to 
install GNUstep on Windows. Once I get the example running, I'll solve 
the issue asap.


Gorm's palette items do not display at all under windows, perhaps it is 
related.


Riccardo

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Quentin Mathé]

Le 7 juin 2010 à 18:39, Doug Simons a écrit :


Thanks Quentin, we appreciate it!

For the sake of tracking this issue, I've opened bug #30069 in the  
bug system.


ok. For now, I'm still trying to get GNUstep core & Gorm from svn  
trunk properly installed on top of a GNUstep install with the Windows  
installers from this page:  http://www.gnustep.org/experience/Windows.html
I initially tried an install from scratch with the README.MinGW doc,  
but I had various issues and had to give up on the fact GCC was unable  
to find the libobjc headers when everything was set up.


On my new install, when compiling the core libs, GNUstep Base and Gui  
headers appear to be installed incorrectly. e.g. GNUstep/Local/Headers/ 
Foundation once installed contains no headers and GNUstep/Local/ 
Library/Headers/AppKit contains the headers that should be the  
GNUstepGUI directory (quite weird). As a result of this,  
GSXibLoading.h is currently not found when I try to compile Gorm.


SystemPreferences from svn trunk once compiled and installed is also  
unable to find libPreferencePanes-1.dll each time a .prefPane is  
loaded (I get a warning dialog and an empty SystemPreferences window  
once the app launch is done).


If you have suggestions to solve these problems, I'm interested :-)

Cheers,
Quentin.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Nicola Pero]

On 8 Jun 2010, at 10:54, Quentin Mathé wrote:



Le 7 juin 2010 à 18:39, Doug Simons a écrit :


Thanks Quentin, we appreciate it!

For the sake of tracking this issue, I've opened bug #30069 in the  
bug system.


ok. For now, I'm still trying to get GNUstep core & Gorm from svn  
trunk properly installed on top of a GNUstep install with the  
Windows installers from this page:  http://www.gnustep.org/experience/Windows.html
I initially tried an install from scratch with the README.MinGW doc,  
but I had various issues and had to give up on the fact GCC was  
unable to find the libobjc headers when everything was set up.


Can you give us more information on the issues you had ?  I updated  
the README.MinGW doc a couple of months ago or so.  If it stopped  
working (because of changes
in MinGW or somewhere else) I'd like to know, so I can update it  
again :-)


Thanks


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Doug Simons]

Quentin,

I don't know if this will help you or not, but we install everything in core in 
the SYSTEM domain, which requires these steps:

cd base
./configure --with-installation-domain=SYSTEM
make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install

cd ../gui
make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install

cd ../back
make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install

The ./configure step is only needed in base. If you have previously installed 
things, you may need to do a 'make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM 
distclean' in each directory first.

Good luck!

Doug

On Jun 8, 2010, at 3:54 AM, Quentin Mathé wrote:

> 
> Le 7 juin 2010 à 18:39, Doug Simons a écrit :
> 
>> Thanks Quentin, we appreciate it!
>> 
>> For the sake of tracking this issue, I've opened bug #30069 in the bug 
>> system.
> 
> ok. For now, I'm still trying to get GNUstep core & Gorm from svn trunk 
> properly installed on top of a GNUstep install with the Windows installers 
> from this page:  http://www.gnustep.org/experience/Windows.html
> I initially tried an install from scratch with the README.MinGW doc, but I 
> had various issues and had to give up on the fact GCC was unable to find the 
> libobjc headers when everything was set up.
> 
> On my new install, when compiling the core libs, GNUstep Base and Gui headers 
> appear to be installed incorrectly. e.g. GNUstep/Local/Headers/Foundation 
> once installed contains no headers and GNUstep/Local/Library/Headers/AppKit 
> contains the headers that should be the GNUstepGUI directory (quite weird). 
> As a result of this, GSXibLoading.h is currently not found when I try to 
> compile Gorm.
> 
> SystemPreferences from svn trunk once compiled and installed is also unable 
> to find libPreferencePanes-1.dll each time a .prefPane is loaded (I get a 
> warning dialog and an empty SystemPreferences window once the app launch is 
> done).
> 
> If you have suggestions to solve these problems, I'm interested :-)
> 
> Cheers,
> Quentin.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Eric Wasylishen]

Hey Quentin,
For setting up a development environment on Windows I always follow
this procedure:

1. Run the windows installers (msys system, core, devel)
2. Open the GNUstep shell
3. Navigate to your checkout of trunk and run 'make install' in base,
gui, and back.

I recently started to get permission denied errors when running 'make
install' on Windows7, so I open the GNUstep shell as an administrator.
Otherwise this procedure has worked for me with no problems.

btw, I just updated the wiki with some instructions on getting
TortiseSVN to remember your private key password.
(http://wiki.gnustep.org/index.php/Using_Subversion)

Regards,
Eric

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Quentin Mathé]

Le 8 juin 2010 à 18:00, Doug Simons a écrit :


Quentin,

I don't know if this will help you or not, but we install everything  
in core in the SYSTEM domain, which requires these steps:


cd base
./configure --with-installation-domain=SYSTEM
make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install

cd ../gui
make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install

cd ../back
make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install

The ./configure step is only needed in base. If you have previously  
installed things, you may need to do a 'make  
GNUSTEP_INSTALLATION_DOMAIN=SYSTEM distclean' in each directory first.


Thanks a lot, this proved to be helpful. I now have several  
applications that run fine such as Gorm and SystemPreferences :-)

I can now tackle the drawing issue for real.

Cheers,
Quentin.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Quentin Mathé]

Hey Eric,

Le 8 juin 2010 à 20:28, Eric Wasylishen a écrit :


For setting up a development environment on Windows I always follow
this procedure:

1. Run the windows installers (msys system, core, devel)
2. Open the GNUstep shell
3. Navigate to your checkout of trunk and run 'make install' in base,
gui, and back.


That's what I did, but apparently something went wrong in my case.


I recently started to get permission denied errors when running 'make
install' on Windows7, so I open the GNUstep shell as an administrator.
Otherwise this procedure has worked for me with no problems.


Here I initially had permission errors (due to Vista) everytime  
'install' was used. I solved it by installing the files attached to  
this bug report: 

And then typing: touch /bin/install /bin/install-info

It would be nice if the msys-system installer could package these  
files and call touch as required.



btw, I just updated the wiki with some instructions on getting
TortiseSVN to remember your private key password.
(http://wiki.gnustep.org/index.php/Using_Subversion)


ok. I'm using the command-line client for now.

Cheers,
Quentin.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Quentin Mathé]

On Wed, Jun 9, 2010 at 4:42 PM, Quentin Mathé  wrote:

I now have several applications that run fine such as Gorm and
> SystemPreferences :-)
> I can now tackle the drawing issue for real.
>

I have started to work on the various drawing issues I have observed with
the Windows backend. This backend has issues very similar to the one I
initially reported for the Cairo backend (e.g. composite is broken in
rotated coordinates).
However GDI and Cairo are not the same, so I won't be able to just copy the
Cairo implementation as I initially hoped it.

Since I don't know much about GDI and there are more than a single drawing
issue, I think it's going to take me a week or so to figure out the right
implementation.

Can I use the updated GDI API introduced with Windows 2000? I doubt anyone
is currently interested in deploying Windows applications on older Windows
versions, but let me know… I'm interested in using SetWorldTransform() and
similar to support stuff like rotation.

Doug, if you are stuck because of the issues I introduced, feel free to roll
back my changes (r30523 and 30524)…

Cheers,
Quentin.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Riccardo Mottola]

Hi,

Can I use the updated GDI API introduced with Windows 2000? I doubt anyone
is currently interested in deploying Windows applications on older Windows
versions, but let me know… I'm interested in using SetWorldTransform() and
similar to support stuff like rotation.

Doug, if you are stuck because of the issues I introduced, feel free to roll
back my changes (r30523 and 30524)…
   


Yes, Windows2000 is fine. I use it regularly with GNUstep. W2K is itself 
quite old but still widespread.
What "older" could we support? Only WinNT4, because all the other 
windows versions wouldn't be supported by recent mingw anymore, which 
now requires a "Nt class" kernel. I don't have an NT4 machine available, 
I don't know if anybody even tried GNUstep there the past *years*.


If possible, however, I'd refrain from using XP only call and keep W2K 
support.


Riccardo

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Doug Simons]

Hi Quentin,

Thanks for working on this! We look forward to rolling ahead once everything is 
working. Windows XP and later is all that matters to us.

Cheers,

Doug

On Jun 11, 2010, at 4:46 AM, Quentin Mathé wrote:

> On Wed, Jun 9, 2010 at 4:42 PM, Quentin Mathé  wrote:
> 
> I now have several applications that run fine such as Gorm and 
> SystemPreferences :-)
> I can now tackle the drawing issue for real.
> 
> I have started to work on the various drawing issues I have observed with the 
> Windows backend. This backend has issues very similar to the one I initially 
> reported for the Cairo backend (e.g. composite is broken in rotated 
> coordinates).
> However GDI and Cairo are not the same, so I won't be able to just copy the 
> Cairo implementation as I initially hoped it. 
> 
> Since I don't know much about GDI and there are more than a single drawing 
> issue, I think it's going to take me a week or so to figure out the right 
> implementation.
> 
> Can I use the updated GDI API introduced with Windows 2000? I doubt anyone is 
> currently interested in deploying Windows applications on older Windows 
> versions, but let me know… I'm interested in using SetWorldTransform() and 
> similar to support stuff like rotation.
> 
> Doug, if you are stuck because of the issues I introduced, feel free to roll 
> back my changes (r30523 and 30524)…
> 
> Cheers,
> Quentin.
> 

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[David Chisnall]

On 11 Jun 2010, at 18:51, Riccardo Mottola wrote:

> What "older" could we support? Only WinNT4, because all the other windows 
> versions wouldn't be supported by recent mingw anymore, which now requires a 
> "Nt class" kernel. I don't have an NT4 machine available, I don't know if 
> anybody even tried GNUstep there the past *years*.

I actually own a copy of NT 4 (I didn't pay for it - MS was handing them out at 
the launch to anyone who didn't run away fast enough).  I could install it in a 
VM and test GNUstep if we actually care about this platform.  I think I 
actually have it installed on a P233 that I use for resting my coffee cup when 
I'm sitting in a comfy chair, but I've not tried booting that machine for 4-5 
years, so I might have NetBSD or something else random installed instead...

Given that I haven't run NT4 for almost a decade, I don't especially think it's 
worth supporting, and if even Riccardo doesn't run it, probably no one else 
does either...

David

-- Sent from my IBM 1620


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Lars Sonchocky-Helldorf]

Am 11.06.2010 um 19:51 schrieb Riccardo Mottola:


Hi,
Can I use the updated GDI API introduced with Windows 2000? I  
doubt anyone
is currently interested in deploying Windows applications on older  
Windows
versions, but let me know… I'm interested in using  
SetWorldTransform() and

similar to support stuff like rotation.

Doug, if you are stuck because of the issues I introduced, feel  
free to roll

back my changes (r30523 and 30524)…



Yes, Windows2000 is fine. I use it regularly with GNUstep. W2K is  
itself quite old but still widespread.


Mhh, must be something below 1% worldwide as you can see here:

http://gs.statcounter.com/#os-ww-monthly-200906-201006
http://gs.statcounter.com/#os-ww-monthly-200906-201006-bar

The only continent where Windows 2000 has still a noteworthy userbase  
seems to be Asia:


http://gs.statcounter.com/#os-as-monthly-200906-201006
http://gs.statcounter.com/#os-as-monthly-200906-201006-bar


cheers,

Lars



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[David Chisnall]

On 11 Jun 2010, at 21:39, Lars Sonchocky-Helldorf wrote:

>> Yes, Windows2000 is fine. I use it regularly with GNUstep. W2K is itself 
>> quite old but still widespread.
> 
> Mhh, must be something below 1% worldwide as you can see here:
> 
> http://gs.statcounter.com/#os-ww-monthly-200906-201006
> http://gs.statcounter.com/#os-ww-monthly-200906-201006-bar
> 
> The only continent where Windows 2000 has still a noteworthy userbase seems 
> to be Asia:
> 
> http://gs.statcounter.com/#os-as-monthly-200906-201006
> http://gs.statcounter.com/#os-as-monthly-200906-201006-bar

Web hit counters can be quite misleading here.  The only large deployment of 
Win2K that I'm aware of (a few hundred thousand seats) is on an internal 
network, with no direct access to the Internet.   I'm not sure what they run on 
their Internet-facing machines - it may also be Win2K, but that would only 
account for about 1% of their total number of PCs.

David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Gregory Casamento]

Win2k is not so common as you might think:

http://www.w3schools.com/browsers/browsers_os.asp

that data indicates that it's being used by about 0.4% of all users
worldwide.   While this might not be the most accurate assessment of
the actual installed base, I believe it's the best statistic we have.

There are a number of issues with continuing to use gdi:

1) issues with compositing
2) not hardware accelerated
3) officially deprecated and will not see either bug fixes or new features
4) will likely disappear in a future release of windows.

GC

On Friday, June 11, 2010, Riccardo Mottola  wrote:
> Hi,
>
> Can I use the updated GDI API introduced with Windows 2000? I doubt anyone
> is currently interested in deploying Windows applications on older Windows
> versions, but let me know… I'm interested in using SetWorldTransform() and
> similar to support stuff like rotation.
>
> Doug, if you are stuck because of the issues I introduced, feel free to roll
> back my changes (r30523 and 30524)…
>
>
>
> Yes, Windows2000 is fine. I use it regularly with GNUstep. W2K is itself 
> quite old but still widespread.
> What "older" could we support? Only WinNT4, because all the other windows 
> versions wouldn't be supported by recent mingw anymore, which now requires a 
> "Nt class" kernel. I don't have an NT4 machine available, I don't know if 
> anybody even tried GNUstep there the past *years*.
>
> If possible, however, I'd refrain from using XP only call and keep W2K 
> support.
>
> Riccardo
>
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
>

-- 
Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc.
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[David Wetzel]

Hi folks,

Am 12.06.2010 um 15:52 schrieb Gregory Casamento:

> Win2k is not so common as you might think:
> 
> http://www.w3schools.com/browsers/browsers_os.asp
> 
> that data indicates that it's being used by about 0.4% of all users
> worldwide.  

That is just from the logs of that single web site, right?
Anyway http://en.wikipedia.org/wiki/Windows_2000 says:

Over ten years after its release, it continues to receive patches for security 
vulnerabilities nearly every month and will continue to do so until 13 July 
2010.

Well apart from running some old software on VMs, I see no real value of 
running W2k.
If our code is easier to maintain and future proof (if one can say so on 
windows) we should just go with XP+
Private users will most probably run UNIX to run GNUstep and when it comes to 
corporate users, I would fire anybody who uses a system that has no security 
patches on a normal end users desktop.

From 2009 to 2010 the use of w2k has been gone down by 50%:

http://www.heise.de/newsticker/meldung/Firefox-Fast-40-Prozent-Marktanteil-in-Europa-969288.html

OS  March 2010  March  2009
Windows XP  45,1 %  56,6 %
Windows 7   17,8 %  0,6 %
Linux   13,5 %  13,9 %
Windows Vista   8,4 %   14,1 %
Mac OS  8,2 %   7,7 %
Other/Unk.  3,6 %   2,4 %
Windows 20001,4 %   3,0 %
Windows .NET1,4 %   1,6 %
UNIX0,6 %   -


David Wetzel


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Riccardo Mottola]

Hi,

first of all: the original question of Quentin was if it is fine to use 
W2K functions by breaking "older" platforms. A clear and sane reasoning 
showed that there is no problem with that, "older" platforms are out of 
our scope or not supportable since mingw does not support them.


This is the topic. We agreed on an answer without a vote against.
This list has the habit of too often going astray because we are moved 
by personal opinions. This leads to discussion which is good, but 
generates also often discussion threads that resemble wars and lead to 
conflicts among users and developers.


Gregory Casamento wrote:

Win2k is not so common as you might think:

http://www.w3schools.com/browsers/browsers_os.asp

that data indicates that it's being used by about 0.4% of all users
worldwide.   While this might not be the most accurate assessment of
the actual installed base, I believe it's the best statistic we have.
   
As written by David, this kind of statistic is quite unrealistic. 
Surely, few people will use W2K for browsing, but it is still deployed 
on machine like servers or workstations of "Internal" use. SInce we want 
GNUstep to work on Servers too...
By the same reasoning it would not be useful to support W2k3 ! Wow, a 
sloppy 1.3% ?
Yet go into a datacenter and count up how many servers run W2k3 or old 
W2k...


Maybe we should stop supporting Linux? It is used by less than 5% of the 
people browsing.


GNUstep shall remain of general purpose. Suppose you want to write a 
server application which has a GUI (absolutely standard on a windows 
system).


Also, our current win32 backend probably almost supports winCE, not a 
bad thing, isn't it?


A reasonable solution could be to root win32 backend into GDI and leave 
"advanced" support do cairo on windows. And bet, there can be an use of 
the pure win32 backend.



3) officially deprecated and will not see either bug fixes or new features
4) will likely disappear in a future release of windows.
GDI has such a large user base and windows relies heavy on 
compatibility. So surely it won't get features, but I don't expect it to 
disappear so soon. It was told dead with Vista yet it still works on 7.


Riccardo

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Quentin Mathé]

Le 7 juin 2010 à 19:02, Riccardo Mottola a écrit :


Hi,


Did you have a chance to try this on Windows yet? We are stuck on  
moving forward with  any new updates in gui or back until this is  
resolved, which is not good.


I haven't yet, I was away for the week-end. I'm currently finishing  
to install GNUstep on Windows. Once I get the example running, I'll  
solve the issue asap.


Gorm's palette items do not display at all under windows, perhaps it  
is related.


Fixed for me now with r30829

Quentin.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Nicola Pero]

Can you give us more information on the issues you had ?  I updated  
the README.MinGW doc a couple of months ago or so.  If it stopped  
working (because of changes
in MinGW or somewhere else) I'd like to know, so I can update it  
again :-)


Sorry for the late reply.

Here are the issues I encountered with MinGW/MSys 1.0.11 (including  
GCC 3.4.5):
- the libxml 2.7.6 source didn't compile with GCC. I worked around  
it by installing the binary available at http://www.zlatkovic.com/libxml.en.html
- gnustep-make didn't add -lpthread whereas I configured it with -- 
thread-lib=posix. I had to add -lpthread to objc_threaded by  
editing /usr/local/share/GNUstep/Makefiles/config.make directly
- make install doesn't work on Vista because of permission issues. I  
solved the issue as I explained previously here: http://lists.gnu.org/archive/html/gnustep-dev/2010-06/msg00055.html
- gnustep-base didn't compile. GCC was unable to find the objc  
headers although they were properly installed in /usr/local/include  
and GCC --print-search-dirs was reporting the right header search  
paths


Thanks Quentin, I guess I'll have to try again :-)

I don't have Windows Vista though, but I added a mention of the  
installation permission problem in the README.MinGW.


Did you use the latest README.MinGW from core/make/Documentation ?

I'm asking because I was checking, and in the README.MinGW mentions to  
configure gnustep-make using


./configure --with-layout=fhs --with-thread-lib=-lpthread

but you mention --with-thread-lib=posix - maybe that was a typo ?

Thanks

___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Quentin Mathé]

Hi Nicola,

Le 8 juin 2010 à 11:58, Nicola Pero a écrit :


On 8 Jun 2010, at 10:54, Quentin Mathé wrote:


Le 7 juin 2010 à 18:39, Doug Simons a écrit :


Thanks Quentin, we appreciate it!

For the sake of tracking this issue, I've opened bug #30069 in the  
bug system.


ok. For now, I'm still trying to get GNUstep core & Gorm from svn  
trunk properly installed on top of a GNUstep install with the  
Windows installers from this page:  http://www.gnustep.org/experience/Windows.html
I initially tried an install from scratch with the README.MinGW  
doc, but I had various issues and had to give up on the fact GCC  
was unable to find the libobjc headers when everything was set up.


Can you give us more information on the issues you had ?  I updated  
the README.MinGW doc a couple of months ago or so.  If it stopped  
working (because of changes
in MinGW or somewhere else) I'd like to know, so I can update it  
again :-)


Sorry for the late reply.

Here are the issues I encountered with MinGW/MSys 1.0.11 (including  
GCC 3.4.5):
- the libxml 2.7.6 source didn't compile with GCC. I worked around it  
by installing the binary available at http://www.zlatkovic.com/libxml.en.html
- gnustep-make didn't add -lpthread whereas I configured it with -- 
thread-lib=posix. I had to add -lpthread to objc_threaded by editing / 
usr/local/share/GNUstep/Makefiles/config.make directly
- make install doesn't work on Vista because of permission issues. I  
solved the issue as I explained previously here: http://lists.gnu.org/archive/html/gnustep-dev/2010-06/msg00055.html
- gnustep-base didn't compile. GCC was unable to find the objc headers  
although they were properly installed in /usr/local/include and GCC -- 
print-search-dirs was reporting the right header search paths


Cheers,
Quentin.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: Testing for drawing fixes r30523

[Quentin Mathé]

Le 23 juin 2010 à 14:35, Nicola Pero a écrit :



Can you give us more information on the issues you had ?  I  
updated the README.MinGW doc a couple of months ago or so.  If it  
stopped working (because of changes
in MinGW or somewhere else) I'd like to know, so I can update it  
again :-)


Sorry for the late reply.

Here are the issues I encountered with MinGW/MSys 1.0.11 (including  
GCC 3.4.5):
- the libxml 2.7.6 source didn't compile with GCC. I worked around  
it by installing the binary available at http://www.zlatkovic.com/libxml.en.html
- gnustep-make didn't add -lpthread whereas I configured it with -- 
thread-lib=posix. I had to add -lpthread to objc_threaded by  
editing /usr/local/share/GNUstep/Makefiles/config.make directly
- make install doesn't work on Vista because of permission issues.  
I solved the issue as I explained previously here: http://lists.gnu.org/archive/html/gnustep-dev/2010-06/msg00055.html
- gnustep-base didn't compile. GCC was unable to find the objc  
headers although they were properly installed in /usr/local/include  
and GCC --print-search-dirs was reporting the right header search  
paths


Thanks Quentin, I guess I'll have to try again :-)

I don't have Windows Vista though, but I added a mention of the  
installation permission problem in the README.MinGW.


Did you use the latest README.MinGW from core/make/Documentation ?


Yes.

I'm asking because I was checking, and in the README.MinGW mentions  
to configure gnustep-make using


./configure --with-layout=fhs --with-thread-lib=-lpthread

but you mention --with-thread-lib=posix - maybe that was a typo ?


I cannot remember whether I used posix or -lpthread when configuring  
gnustep-make. I might well have made the typo in my mail reply.


Cheers,
Quentin.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev