Follow-up Comment #3, bug #25411 (project gnustep):
Hmm, this is a possible interpretation of the required behaviour. Could
anybody please test this on Apple to see what they are doing?
I found that Apple seems to disregard that mask when doing a drop, so I am
not sure what they are doing with
Follow-up Comment #2, bug #25397 (project gnustep):
Could you please explain once more what you are suggesting?
Should we just set the NSAlternateKeyMask on Windows when we get an AltGr
key? (Treating AltGr as Alt-R) Aren't we loosing informations about modifiers
that way?
Another problem with
Follow-up Comment #3, bug #25395 (project gnustep):
I see this is a moot topic here. I did consult only the Apple documentation
and was a bit confused by things now working properly afterwards.
An added point is here probably that esc cannot be handled by characters
and it is not present among
Update of bug #25394 (project gnustep):
Status: Ready For Test = Fixed
Open/Closed:Open = Closed
___
Follow-up Comment #2:
seems fixed here
Follow-up Comment #5, bug #25343 (project gnustep):
I was able to complete a build on Windows XP right now. Without further
imfornation, I would consider this bug as invalid.
___
Reply to this item at:
URL:
http://savannah.gnu.org/bugs/?25425
Summary: Framework resource loading not functioning properly
on ARM based Linux
Project: GNUstep
Submitted by: gcasa
Submitted on: Wed 28 Jan 2009 11:05:40 AM EST
Category:
Follow-up Comment #1, bug #25425 (project gnustep):
What operating system is being used ?
Maybe symbolic links don't work or are not used on that operating system ?
Also, can you include the results of gnustep-make's ./configure, and any
other output/raw data that can help with figuring it out
URL:
http://savannah.gnu.org/bugs/?25427
Summary: Undefined References building GDL2 on Mingw
Project: GNUstep
Submitted by: glpunzi
Submitted on: Wed Jan 28 16:34:00 2009
Category: gdl2
Severity: 3 -
Follow-up Comment #4, bug #25415 (project gnustep):
I was tracking Gorm/GDL2 from svn daily. (Your videos were perfectly timed
for a proof-of-concept for one of my clients next week, thus the reason for my
enthusiastic bug reports ;)
I think making the error messages more explicit are a good
Follow-up Comment #2, bug #25425 (project gnustep):
Here's the uname -a output:
---
Linux dhcppc1 2.4.20-celf3 #1 Fri Sep 5 21:48:01 HKT 2008 mips GNU/Linux
Make configure output...
---
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C
Follow-up Comment #3, bug #25425 (project gnustep):
Could this be due to a limitation in the ARM Linux linker? Can it not handle
dynamic links to libraries?
I also noticed that in the Libraries directory the libs there are copies, not
links, to the ones in the frameworks. This seems to
Follow-up Comment #4, bug #25425 (project gnustep):
It sounds to me like a problem with the installation of the framework rather
than a problem with the loading mechanism.
If I understand frameworks correctly, all the resources are supposed to be in
subdirectories of the versions folder, and
Follow-up Comment #5, bug #25425 (project gnustep):
I suppose getting it from the top level would, if a given application was
looking for a given version of the library resources... getting it from the
top level at that point could cause issues.
So, it does sound like a problem with the
Follow-up Comment #6, bug #25425 (project gnustep):
Can you go in the framework that doesn't work, and do
make distclean
make messages=yes
make messages=yes install
and send me the output ?
Thanks
___
Reply to this item at:
Additional Item Attachment, bug #25425 (project gnustep):
File name: installation.log Size:12 KB
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25425
___
Message
Follow-up Comment #8, bug #25425 (project gnustep):
Just FYI, this does happen on all other frameworks.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25425
___
Message sent
Follow-up Comment #9, bug #25425 (project gnustep):
Greg,
can you please post the output of ls -lR of the framework so that others can
take a look at it's anatomy and if parts are built correctly?
BTW: it is a MIPS (not ARM) machine.
___
Follow-up Comment #10, bug #25425 (project gnustep):
I'm confused by your logs - the way gnustep-make configured
itself does not match the way it is behaving. :-(
The only explanation I could think of is that the gnustep-make
you are using to compile and install is not the gnustep-make
v2.0.8
Follow-up Comment #6, bug #25343 (project gnustep):
install -p -m 644 gui.make
/usr/local/share/GNUstep/Makefiles/Additional/gui.make
./install: line 1: 1: command not found
That is due to gnustep-make's configure, which for mingw32 sets
INSTALL=install -p
Presumably when executed inside
Follow-up Comment #3, bug #25397 (project gnustep):
Since AltGr is not part of the OpenStep/Cocoa API, I see two possible options
here:
1) Just ignore that AltGr key is pressed
2) Set NSAlternateKeyMask
I'm not really sure about what is the better approach here. It looks like
Apple and NeXT did
Follow-up Comment #11, bug #25425 (project gnustep):
---
r...@dhcppc1:/usr/GNUstep/System/Library/Makefiles# make -v
GNU Make 3.81
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for
Update of bug #25425 (project gnustep):
Summary: Framework resource loading not functioning properly
on ARM based Linux = Framework resource loading not functioning properly on
MIPS based Linux
___
Follow-up Comment #13:
Follow-up Comment #12, bug #25425 (project gnustep):
Here is the ls -lR... this happens with all frameworks...
r...@dhcppc1:/usr/GNUstep/Local/Library/Frameworks/Addresses.framework# ls
-lR
.:
total 2122
-rwxr-xr-x 1 root root 542014 Jan 28 15:38 Addresses
drwxr-xr-x 1 root root 2048 Jan 28
Update of bug #25425 (project gnustep):
Summary: Framework resource loading not functioning properly
on MIPS based Linux = Framework resource loading not functioning properly on
ARM based Linux
___
Follow-up Comment #14:
Update of bug #25163 (project gnustep):
Open/Closed:Open = Closed
___
Follow-up Comment #4:
I reviewed gnustep-make's uninstallation code and it should
be uninstalling much more carefully
Follow-up Comment #7, bug #25307 (project gnustep):
I have implemented and added a test to the Testing directory which shows that
tryLock does not throw an exception when locking the same lock twice in the
same thread.
I am going to put additional tests into this test case, if necessary.
Update of bug #25307 (project gnustep):
Status: Ready For Test = In Progress
Open/Closed: In Test = Open
___
Reply to this item at:
Update of bug #25425 (project gnustep):
Summary: Framework resource loading not functioning properly
on ARM based Linux = Framework resource loading not functioning properly on
MIPS based Linux
___
Follow-up Comment #15:
Update of bug #25425 (project gnustep):
Status:None = Invalid
Open/Closed:Open = Declined
___
Reply to this item at:
Follow-up Comment #7, bug #25407 (project gnustep):
This appears to have been fixed by a change in DBModeller, please confirm.
Thanks, GC
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25407
Update of bug #25407 (project gnustep):
Open/Closed:Open = Closed
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25407
___
Follow-up Comment #8, bug #25307 (project gnustep):
The test is called locktest.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?25307
___
Message sent via/by Savannah
32 matches
Mail list logo
