Update of bug #12578 (project gnustep):
Status:None = Fixed
Open/Closed: In Test = Closed
___
Follow-up Comment #2:
Closed as there was
Update of bug #4068 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #6:
Closed as there was no follow up for two years.
Update of bug #4497 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #2:
Closed as tehre was no follow up for two years.
Update of bug #9788 (project gnustep):
Open/Closed:Declined = Closed
___
Follow-up Comment #2:
Changed from declined to closed.
___
Update of bug #13046 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #5:
Reported as resolved
___
Reply to
Update of bug #13140 (project gnustep):
Status:None = In Progress
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
The probelm here is
Update of bug #4066 (project gnustep):
Open/Closed:Declined = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=4066
Update of bug #3824 (project gnustep):
Status:None = Invalid
Open/Closed:Declined = Closed
___
Reply to this item at:
Update of bug #3457 (project gnustep):
Status:None = Wont Fix
Open/Closed:Declined = Closed
___
Reply to this item at:
Update of bug #4664 (project gnustep):
Open/Closed:Declined = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=4664
Update of bug #7509 (project gnustep):
Open/Closed:Declined = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=7509
Update of bug #7876 (project gnustep):
Status:None = Wont Fix
Open/Closed:Declined = Closed
___
Reply to this item at:
Update of bug #3292 (project gnustep):
Status:None = Invalid
Open/Closed:Declined = Closed
___
Reply to this item at:
Update of bug #12530 (project gnustep):
Open/Closed:Declined = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=12530
Update of bug #9601 (project gnustep):
Open/Closed:Declined = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=9601
Update of bug #11144 (project gnustep):
Open/Closed:Declined = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=11144
Update of bug #8893 (project gnustep):
Open/Closed:Declined = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=8893
Anton Zinoviev wrote:
On Sat, Jun 25, 2005 at 02:04:43PM +0300, Enrico Sersale wrote:
The roler of the mouse doesn't work for the horizontal scroll bar under
the shelf in the GWorkspace's Viewers.
Not fixable because my mouse have not a roller.
I see - the roler doesn't work for the
Mark Frank wrote:
* After looking at your on-line documentation, I am uncertain whether
display post script is supported. I have some code inside a view such
as,
for(i=0; iNUMBER_LINES; i++)
{
...;
userPathOps[op_ctr++] = dps_lineto;
}
Adam Fedor wrote:
This seems fine to me. Anyone have a comment or can I add it?
Fine for me as well. I am just still not able to work under Windows,
thats why I stayed out of that thread.
From: Marc Brünink [mailto:[EMAIL PROTECTED]
If I trust
Follow-up Comment #2, bug #13705 (project gnustep):
As this looks like an important problem I tried hard to reproduce it with a
simple program, but failed to.
A small loop made up of the lines you posted does not produce a memory leak:
int main (int argc, const char *argv[])
{
int i;
Hi Saso,
Sašo Kiselkov wrote:
I found that when my code returns an NSAttributedString as the value for a
table
data cell it doesn't display it as an attributed string, but instead by
sending
it description (which obviously isn't right, is it?). The problem is in the
code of NSCell's
Sašo Kiselkov wrote:
Quoting Fred Kiefer [EMAIL PROTECTED]:
Sa#65533;o Kiselkov wrote:
I found that when my code returns an NSAttributedString as the value for a
table
data cell it doesn't display it as an attributed string, but instead by
sending
it description (which obviously isn't right
Christopher Armstrong wrote:
Attached is a patch against gnustep-back to enable use GDIPlus, as
well as a wrapper library. This is experimental, so no guarantees are
made, no warranties are provided.
thats quite a nice patch and a great starting point. The problem with it
is that only the
Follow-up Comment #1, bug #14315 (project gnustep):
Is NSSAXParser a new class in Foundation or where does it come from?
What GNUstep already offers is the class NSXMLParser. In which way do these
two classes differ? Could your application be build on top of NSXMLParser?
I am not saying
Follow-up Comment #1, bug #14251 (project gnustep):
Which window manager are you using? The window decoration is most likely not
added by the X server itself, but by the window manager. We need to convince
each single window manager not do it an perhaps this one we ignored up to
now.
Follow-up Comment #2, bug #13873 (project gnustep):
Gregs analysis is correct, this is the problem of the AppKit not storing the
typing attributes for NSTextView. Asusual with encoding stuff, any change
here wont be backwards compatible. That's why I would like to have an agreed
on solution, so
Follow-up Comment #1, bug #14317 (project gnustep):
You are correct that bug reports on make_services are very common in GNUstep.
But normally this is just because make_services is the first GNUstep tool
being run after compiling GNUstep. So most errors here jsut indicate that
something went
Follow-up Comment #1, bug #14497 (project gnustep):
Could you please try to drag files onto the NSOpenPanel? I remember that
Richard did implement this about two years ago. If this is not possible from
GWorkspace, we need to find out, what is going wrong between these two.
Follow-up Comment #3, bug #14759 (project gnustep):
Quentin, I think that performSelectorOnMainThread:withObject:waitUntilDone:
is implemented in base and hope that it is actually working correctly, as it
gets used by the gui view refreshing quiet heavily.
Update of bug #14775 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Fixed in CVS.
Update of bug #14497 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #11936 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Declined
___
Reply to this item at:
Update of bug #3956 (project gnustep):
Item Group: Bug = Change Request
Status:None = In Progress
___
Follow-up Comment #6:
I added a bit of
Follow-up Comment #1, bug #13592 (project gnustep):
I am willing to implement a patch here, but based on which data, available to
the backend, should the window class be choosen? Should we change the window
class, when that property changes?
Update of bug #12300 (project gnustep):
Category: Gui/AppKit = Backend
___
Follow-up Comment #2:
Changed the bug category to backend, as this problem seems to show up only
with the art
Update of bug #14901 (project gnustep):
Category:None = Gui/AppKit
Item Group:None = Bug
Status:None = Fixed
Assigned to:
Hi Georg,
Georg Fleischmann wrote:
here is a patch for GMAppKit to allow loading of images from the owners
bundle
(not just the main bundle).
could you just explain shortly why this patch is needed and also why
this is not a general problem of the way [NSImage imageNamed:] is
Update of bug #14987 (project gnustep):
Severity: 4 - Important = 2 - Minor
Assigned to:None = FredKiefer
___
Follow-up Comment #1:
First a short
Hi Chris,
Chris B. Vetter wrote:
On 11/17/05, Gregory John Casamento [EMAIL PROTECTED] wrote:
Follow-up Comment #2, bug #14987 (project gnustep):
[...]
As for which way to go, I believe that kludging it for WindowMaker might not
be a bad idea in the short term, but we should ultimately try
Update of bug #14759 (project gnustep):
Status:None = Wont Fix
Open/Closed:Open = Closed
___
Follow-up Comment #6:
Closed as we seem
Update of bug #14987 (project gnustep):
Status:None = Ready For Test
___
Follow-up Comment #6:
Should be fixed in CVS
___
Reply to
Follow-up Comment #1, bug #14967 (project gnustep):
I loaded the image into a GNUstep image view application with different
backends, but could not reproduce the problem. Which backend are you using
and does the problem show up at all scales? Maybe it is a scaling glitch in
xlib or art?
Hi Wolfgang,
I see two problems with that patch. First you should not change the
whitespace in a file, this leads to patches that are bigger than needed
and also to wrongly formatted code.
Wolfgang Sourdeau wrote:
NSCell:
- whenever the cell type would change, the _contents ivar would be set
Carlos Adriano Portes wrote:
Why Can I select text using shift+home and shift end in windows but not
in linux application compiled with gnustep?
No idea, why you are able to do so on windows, nor why you wanted to
find out :-)
On GNUstep this does not work as there is no method implemented
Update of bug #15313 (project gnustep):
Category:None = Gui/AppKit
Item Group:None = Bug
Assigned to:None = FredKiefer
Alex Perez wrote:
Georg Fleischmann wrote:
Hi,
here is a patch for [NSMatrix -deselectAllCells] to set the selected
row/column of an empty matrix always to -1 (even if in radio mode
empty selection is not allowed).
This is needed to have the correct starting point after a renew, since
Adam Fedor wrote:
On 2006-02-23 13:11:00 -0700 Vaisburd, Haim [EMAIL PROTECTED] wrote:
The matrix multiplication is not commutative and the last line should be
instead
matrix = matrix_multiply(matrix, tranm);
Do you have a test that shows this is wrong? All my tests work with the
Tamas Mahr wrote:
I have just upgraded my GNUstep using gnustep-startup-0.14.1 on a Fedora Core
4 kernel 2.6.11-1.1369_FC4. Everything was smooth. Then I have compiled and
intalled ProjectCenter.
Now as I try to start it by openapp ProjectCenter.app, the response is:
GNUSTEP Internal
Follow-up Comment #1, bug #16031 (project gnustep):
I don't quite see how the behaviour you describe could happen. Within the
LeaveNotify case the processEvent: method does only assign to the variable
generic.cachedWindow. How could this ever cause a segmentation fault?
No idea who to go ahead
Follow-up Comment #3, bug #16031 (project gnustep):
Thank you for pointing this out to me. I have a further look, but what you
wrote may already be the problem.
___
Reply to this item at:
Update of bug #16031 (project gnustep):
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
___
Follow-up Comment #5:
I could not see the
Update of bug #12680 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #3:
Closed after one year of testing
___
Update of bug #14497 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #3:
Closed after half a year of testing
Update of bug #16031 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #7:
Closed as it is reported as fixed
___
Update of bug #9402 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #4:
The last outstanding item had also been resolved on the day after the last
comment.
Update of bug #11703 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Closed as there was no follow up comment form the originator of this bug for
more then a year.
Update of bug #15710 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #1:
Fixed by Richard in
Update of bug #12459 (project gnustep):
Open/Closed: In Test = Closed
___
Follow-up Comment #2:
Closed as there was no follow up within one year
Update of bug #16218 (project gnustep):
Category: Libraries = Base/Foundation
Status:None = Invalid
Open/Closed:Open = Declined
Update of bug #16218 (project gnustep):
Status: Invalid = Need Info
Open/Closed:Declined = Open
___
Follow-up Comment #4:
I opened up this
Update of bug #16218 (project gnustep):
Status: Need Info = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #6:
It turns out that
Update of bug #16338 (project gnustep):
Category:None = Gui/AppKit
Item Group:None = Bug
Status:None = Fixed
Open/Closed:
Update of bug #15612 (project gnustep):
Category:None = Gui/AppKit
Status:None = Fixed
Assigned to:None = CaS
Open/Closed:
Follow-up Comment #1, bug #16262 (project gnustep):
Which GNUstep backend are you using and where do your fonts come from, if
this is the art backend?
There seem to be name difference between the GNUstep backend font names and
the Postscript font names, but I could not see, where the font
Update of bug #16436 (project gnustep):
Severity: 4 - Important = 3 - Normal
Status:None = Ready For Test
Open/Closed:Open = In Test
Update of bug #16454 (project gnustep):
Category: Gui/AppKit = Backend
Item Group:None = Bug
___
Follow-up Comment #1:
I have to admit
Update of bug #16197 (project gnustep):
Open/Closed:Open = Declined
___
Follow-up Comment #1:
I am not sure to which bug you are refering to. I checked this mail and the
follow ups on that
Follow-up Comment #5, bug #16440 (project gnustep):
You are correct that GNUstep uses this method for both cases, when the window
is already mapped and when it isn't. In the later case your code wont help
anything, in the former it would improve the estimated result for the frame.
In that case
Update of bug #16549 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #5871 (project gnustep):
Severity:1 - Wish = 2 - Minor
Status:None = In Progress
Assigned to: fedor = FredKiefer
Follow-up Comment #3, bug #4730 (project gnustep):
Hi Greg,
could you please check, if Richards changes to the key equivalent handling
resolved this bug as well?
I tried with a simple window with just one button in Gorm and there assigning
return seems to work. It is still a bit strange that
Update of bug #5871 (project gnustep):
Status: In Progress = Fixed
Open/Closed:Open = In Test
___
Follow-up Comment #10:
I did apply your
Follow-up Comment #5, bug #13705 (project gnustep):
Could not reproduce this problem with the xlib backend on Suse 10.1 linux.
(But had other problems with that backend here)
I would think that this problem is specific to solaris. Could you please use
valgrind (or a similar tool) to find out,
Update of bug #13705 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = In Test
Update of bug #5871 (project gnustep):
Status: Fixed = In Progress
___
Follow-up Comment #12:
Wouldn't it be easier if we change the code in [NSView discardCursorRects] to
call [NSWindow
Update of bug #13705 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=13705
Update of bug #16549 (project gnustep):
Open/Closed: In Test = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=16549
Update of bug #17026 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #17025 (project gnustep):
Status:None = Fixed
Assigned to:None = CaS
Open/Closed:Open = Closed
Update of bug #17023 (project gnustep):
Status:None = Fixed
Assigned to:None = CaS
Open/Closed:Open = Closed
Update of bug #17024 (project gnustep):
Status:None = Fixed
Assigned to:None = CaS
Open/Closed:Open = Closed
Update of bug #17022 (project gnustep):
Status:None = Fixed
Assigned to:None = ayers
Open/Closed:Open = Closed
Update of bug #16440 (project gnustep):
Status:None = Fixed
Assigned to:None = FredKiefer
Open/Closed:Open = Closed
Update of bug #17019 (project gnustep):
Category: Gui/AppKit = Backend
Status:None = Fixed
Assigned to:None = CaS
Open/Closed:
Update of bug #17012 (project gnustep):
Status:None = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #1:
I could not
Update of bug #17010 (project gnustep):
Status:None = Fixed
Assigned to:None = CaS
Open/Closed:Open = Closed
Update of bug #17011 (project gnustep):
Status:None = Fixed
Assigned to:None = CaS
Open/Closed:Open = Closed
Update of bug #17006 (project gnustep):
Status:None = Fixed
Assigned to:None = CaS
___
Follow-up Comment #1:
Fixed by Richards
Update of bug #17008 (project gnustep):
Status:None = Fixed
Assigned to:None = CaS
Open/Closed:Open = Closed
Update of bug #17009 (project gnustep):
Status:None = Fixed
Assigned to:None = CaS
Open/Closed:Open = Closed
Update of bug #17006 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #2:
Forgot to set this to closed in last change. Sorry :-)
Follow-up Comment #1, bug #16425 (project gnustep):
Could somebody please retest, if this problem is still occuring? I think it
should be fixed by a patch some time ago.
___
Reply to this item at:
Follow-up Comment #1, bug #17096 (project gnustep):
I tried to reproduce this problem, but I don't understand which window I
should open. Is there any example account I could use to get passed the
initial login screen and to use the program?
Update of bug #17096 (project gnustep):
Status:None = Confirmed
Assigned to:None = FredKiefer
___
Follow-up Comment #3:
With that hint I
Hi Marc,
I always thought that these lines are wrong, but as nobody did complain
I left them in. They have been in the GNUstep code for quite some time now.
What is the example that is failing you? And an even better question,
why didn't you report it on Savannah in the web interface? :-)
I will
to fix it
fast.
Cheers
Fred
Fred Kiefer schrieb:
Hi Marc,
I always thought that these lines are wrong, but as nobody did complain
I left them in. They have been in the GNUstep code for quite some time now.
What is the example that is failing you? And an even better question,
why didn't you
Follow-up Comment #1, bug #17377 (project gnustep):
Just to make sure I understand this correctly, would you say the the GNUstep
behaviour for the case GSX11HandlesWindowDecorations=YES is totally correct?
If not, which problem did I overlook for this case?
For the case
Follow-up Comment #5, bug #17377 (project gnustep):
The code we have there in the different decorators is there on purpose. When
Alexander Malmberg implemented the window decoration handling inside of
GNUstep gui he wanted to end up with things right the way they are now.
I remember there was
Update of bug #17096 (project gnustep):
Status: Confirmed = Ready For Test
Open/Closed:Open = In Test
___
Follow-up Comment #4:
Some time ago I
201 - 300 of 1310 matches
Mail list logo
