Re: Gworkspace with non-fragile abi, etc?

[Lee, Seong-Gu]

On 08/25/2013 05:57 AM, Riccardo Mottola wrote:
> Hi
> Lee, Seong-Gu wrote:
>> Dear GNUstep developers and users,
> First thing: you address different problems of different applications:
> it is best to ask those in different emails. That way the answers will
> form  a thread for each topic and not create a big lump.
>> 1) GWorkspace with non-fragile abi
>>   Other usr applications (Gorm, SystemPreferences, etc.) work well except
>> GWorkspace when compiled with non-fragile abi.
> <...>
>>   It seems to occur error when initializaing NSRect object with
>> NSZeroRect. However, same initialization code from other applications
>> did not make troubles. I cannot know whether NSStringDrawing.m in
>> gnustep-gui or GWorkspace source is wrong.
>>   When NSZeroRect was commented out and gnustep-gui was re-compiled, all
>> works well.
> I have no clues here, there is no direct reference to GWorkspace itself.
> I mostly use GCC and clang and I know it works for both.
> If there is further evidence of a problem in GWorkspace itself, please
> tell me.
>> 4) Localization resources
>>   GNUstep system and applications seem to comprised of many bundles and
>> frameworks which have thier own message resources. However, I cannot
>> figure out whether their resources are shared or separated.
>>   For example, SystemPrerences source tree is consist as like this:
> I think you are here hitting generally the same point I made explicit i
> about SystemPreferences right a couple of days ago and got no answer. I
> was looking into localizing SystemPreferences better eight these days
>>   Though Localizable.strings and .gorm file in each source .lproj were
>> translated before compiling, compiled application still shows partial
>> translation. To comlete localization, resources at generated .app were
>> edited manually.
> "partial" translation may mean different things. The  application may
> not be complete or you are hitting the "bundle problem" I was hitting,
> which may perhaps not be a bug but just something missing which I don't
> know, that's why I asked.
> 
> Grossly said, your application my construct the interface by code or by
> using a Gorm/Nib file.
> 
> in Resources you will find English as the main language, which possinbly
> the interfaces (if used) and a Localizable string files.
> 
> Now, to provide a translation you may supply a whole new interface and a
> new Localizable string file: if the application is written to localize
> all strings not contained in the interface, this should work 100%
> (except Bundles).
> 
> Else, the app might be written to "localize" the interface by resetting
> all the text in the interface, so further languages will just need the
> strings file. This is a lot of work, but helps maintaining only one
> interface. Gworkspace is done that way.
> 
>>
>>   'make_strings' seems not to extract strings at files in sub-directories
>> (have not -r switch in grep, find). If sub-projects have own separated
>> string resource and aggregate to .app when compiled, it would be
>> appropriate. However, compiling does not seem to aggregate localized
>> resources.
> It is a bit a mystery for me too. I need to regenerate GWorkspace's
> strings file which is obsolete, but I am unable to regenerate it as it is.
>>
>> 5) ProjectCenter
>>   ProjectCenter seems to import not .pbproj or .xcodeproj or GNUmakefile
>> but only .pcproj. GNUstep example applications are generated with
>> GNUmakefile not .pcproj. Buildtool and pbxbuild works at terminal. Is
>> there any IDE similar to XCode?
> ProjectCenter is the IDE, although it is not as complete and usable as
> its graphical counterpart Form.
> 
> Examples use GNUmakefile because that's what ultimately gnustep-make uses.
> ProjectCenter works a bit like OpenStep's ProjectBuilder, not Apple's:
> it creates the Makefiles for you and then runs make. That means a
> project done in PC can still be built with make (useful for packagers
> for example or for repeated building without starting Xcode, mixed
> development with another editor, etc). Be careful however not to edit
> them, or PC will overwrite them.
> 
> Riccardo

Dear Ricarrdo,

 Thank you for your advice.
 Firstly, I thought it is not proper to write each problem occurred
every time (too many numbers of messages) so that I sent it as "BATCH".
However, if it is not more suitable to send lump-sum message, I would
separate to a subject per message later.

 Secondly, I have just start to learn objective C, GNUstep, X window.
So, it is not easy to describe the origin of trouble explicitly. If
non-fragile abi problem did not occur at others' environment, it would
be any fracture on my testing environment. More investigation would be
needed.
 I just conjecture ivars fixed offsets of fragile abi worked well, but
variable offsets of non-fragile abi may make troubles from [dots
sizeWithAttributes: fontAttr].width; at FSNBrowserCell.m:87 (GWorkspace)
--> sizeWithAttributes at NSStringDrawing.m:671 (gnustep-gui) -->
boundingRectWithSize at NSStringDrawing.m:677 (gnustep-gui) in GDB
backtrace log quoted and NSStringDrawing.m:681 (FIXME: This ignores
options). In other words, undetermined object size and address of
non-fragile abi would be the cause of trouble. If this hypothesis were
correct, the origin of trouble is not at GWorkSpace source but at
GNUstep core source or libobjc2. All these may be just delirious
utterances from novice and even non-developer (me).

 It was very regrettable to report GWorkSpace error at previous personal
query because gnustep-base check passed only 3526 test then when
libobjc2 svn was troublesome (now base has 7838 passed, 21 dashed hope.
gui has 989 passed, 4 dashed hope). I shall try not to report problems
impetuously.

 Thirdly, about ProjectCenter, not being accustomed with separated shell
window work and GNUmakefile, I envied the intergrated environment of
Visual Studio or XCode (even commercial and expensive) just like "A bad
workman blames his tools".

 Oh, lump-sum message was written again. I would never do this. Bye.

 Sincerely yours,
 Lee, Seong-Gu ( at gmail dot com )