Re: GNUstep - Documentation

[Bob Plymale]

Thank you for the support. If and when I can do a successful install, configure 
and a successful build I will update the docs so the next user has an easier 
time.

Sent from my iPhone

> On Jul 25, 2021, at 6:00 AM, Fred Kiefer  wrote:
> 
> 
> Bob,
> 
> you should not give up too soon. Just ignore the corebase error and go ahead 
> and compile GNUstep gui and core. You will need some extra libraries for 
> these. Not having done a Windows compile in years, I don't remember which 
> ones. But after that you should be able to compile and run your own code.
> 
> Cheers,
> Fred
> 
> On the road
> 
>> Am 25.07.2021 um 11:23 schrieb Bob Plymale :
>> 
>> It seems all of the documentation for install configuration is dated and no 
>> longer works as described, such as the Windows installer, It didn't play 
>> well, so I dropoped it. Then it was recommended to follow the tutorial 
>> gnustep/tools-windows-msvc at https://github.com/gnustep/tools-windows-msvc. 
>> This one had potiential but alas running the build.bat script bombed with 
>> the following errors:
>> 
>> 1 warning generated.
>>  Linking library libgnustep-corebase ...
>> lld-link: error: undefined symbol: __declspec(dllimport) pthread_once
>> >>> referenced by 
>> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:436
>> >>>   
>> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent)
>> >>> referenced by 
>> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:462
>> >>>   
>> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetMain)
>> 
>> lld-link: error: undefined symbol: __declspec(dllimport) pthread_getspecific
>> >>> referenced by 
>> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:438
>> >>>   
>> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent)
>> 
>> lld-link: error: undefined symbol: __declspec(dllimport) pthread_setspecific
>> >>> referenced by 
>> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:442
>> >>>   
>> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent)
>> 
>> lld-link: error: undefined symbol: __declspec(dllimport) pthread_key_create
>> >>> referenced by 
>> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:424
>> >>>   
>> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(_CFRunLoopCreateThreadKey)
>> clang: error: linker command failed with exit code 1 (use -v to see 
>> invocation)
>> make[4]: *** 
>> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Instance/library.make:307: 
>> obj/gnustep-corebase.lib] Error 1
>> make[3]: *** 
>> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Instance/library.make:292: 
>> internal-library-all_] Error 2
>> make[2]: *** 
>> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/rules.make:297: 
>> libgnustep-corebase.all.library.variables] Error 2
>> make[1]: *** 
>> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/library.make:37: 
>> internal-all] Error 2
>> make: *** 
>> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/serial-subdirectories.make:53:
>>  internal-all] Error 2
>> Failed
>> 
>> 
>> 
>> I have some macOS code that I want to make multiplatform so I was leaning 
>> towards rewrite in wxWidgets so my code portable. Basically if I could get 
>> objective-c to work on windows and linux that would be my portable code, and 
>> to say I really enjoy coding in objective-c regardless of what Apple does 
>> with thee version.
>> 
>> 
>> 
>> Bob

Re: GNUstep - Documentation

[Fred Kiefer]

Bob,

you should not give up too soon. Just ignore the corebase error and go ahead 
and compile GNUstep gui and core. You will need some extra libraries for these. 
Not having done a Windows compile in years, I don't remember which ones. But 
after that you should be able to compile and run your own code.

Cheers,
Fred

On the road

Am 25.07.2021 um 11:23 schrieb Bob Plymale :

> It seems all of the documentation for install configuration is dated and no 
> longer works as described, such as the Windows installer, It didn't play 
> well, so I dropoped it. Then it was recommended to follow the tutorial 
> gnustep/tools-windows-msvc at https://github.com/gnustep/tools-windows-msvc. 
> This one had potiential but alas running the build.bat script bombed with the 
> following errors:
> 
> 1 warning generated.
>  Linking library libgnustep-corebase ...
> lld-link: error: undefined symbol: __declspec(dllimport) pthread_once
> >>> referenced by 
> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:436
> >>>   
> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent)
> >>> referenced by 
> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:462
> >>>   obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetMain)
> 
> lld-link: error: undefined symbol: __declspec(dllimport) pthread_getspecific
> >>> referenced by 
> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:438
> >>>   
> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent)
> 
> lld-link: error: undefined symbol: __declspec(dllimport) pthread_setspecific
> >>> referenced by 
> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:442
> >>>   
> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent)
> 
> lld-link: error: undefined symbol: __declspec(dllimport) pthread_key_create
> >>> referenced by 
> >>> C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:424
> >>>   
> >>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(_CFRunLoopCreateThreadKey)
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> make[4]: *** 
> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Instance/library.make:307: 
> obj/gnustep-corebase.lib] Error 1
> make[3]: *** 
> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Instance/library.make:292: 
> internal-library-all_] Error 2
> make[2]: *** 
> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/rules.make:297: 
> libgnustep-corebase.all.library.variables] Error 2
> make[1]: *** 
> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/library.make:37: 
> internal-all] Error 2
> make: *** 
> [/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/serial-subdirectories.make:53:
>  internal-all] Error 2
> Failed
> 
> 
> 
> I have some macOS code that I want to make multiplatform so I was leaning 
> towards rewrite in wxWidgets so my code portable. Basically if I could get 
> objective-c to work on windows and linux that would be my portable code, and 
> to say I really enjoy coding in objective-c regardless of what Apple does 
> with thee version.
> 
> 
> 
> Bob

Re: GNUstep - Documentation

[Bob Plymale]

It seems all of the documentation for install configuration is dated and 
no longer works as described, such as the Windows installer, It didn't 
play well, so I dropoped it. Then it was recommended to follow the 
tutorial gnustep /tools-windows-msvc 
 at 
https://github.com/gnustep/tools-windows-msvc. This one had potiential 
but alas running the build.bat script bombed with the following errors:


/1 warning generated.
 Linking library libgnustep-corebase ...
lld-link: error: undefined symbol: __declspec(dllimport) pthread_once
>>> referenced by 
C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:436

>>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent)
>>> referenced by 
C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:462

>>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetMain)

lld-link: error: undefined symbol: __declspec(dllimport) pthread_getspecific
>>> referenced by 
C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:438

>>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent)

lld-link: error: undefined symbol: __declspec(dllimport) pthread_setspecific
>>> referenced by 
C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:442

>>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(CFRunLoopGetCurrent)

lld-link: error: undefined symbol: __declspec(dllimport) pthread_key_create
>>> referenced by 
C:\Users\bplym\Desktop\tools-windows-msvc\src\gnustep-corebase\Source\CFRunLoop.c:424

>>> obj/libgnustep-corebase.obj/CFRunLoop.c.o:(_CFRunLoopCreateThreadKey)
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)
make[4]: *** 
[/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Instance/library.make:307: 
obj/gnustep-corebase.lib] Error 1
make[3]: *** 
[/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Instance/library.make:292: 
internal-library-all_] Error 2
make[2]: *** 
[/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/rules.make:297: 
libgnustep-corebase.all.library.variables] Error 2
make[1]: *** 
[/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/library.make:37: 
internal-all] Error 2
make: *** 
[/c/GNUstep/x64/Debug/share/GNUstep/Makefiles/Master/serial-subdirectories.make:53: 
internal-all] Error 2

Failed/

/
/

I have some macOS code that I want to make multiplatform so I was 
leaning towards rewrite in wxWidgets so my code portable. Basically if I 
could get objective-c to work on windows and linux that would be my 
portable code, and to say I really enjoy coding in objective-c 
regardless of what Apple does with thee version.



Bob/
/

Re: GNUStep Documentation– General Improvements

[BTS]

On 4 Sep 2011, at 01:31, BTS wrote:

 
 There are a number of things that concern me about the manner in which
 GNUStep is doccumented.
 
 1. The first of which is that in order to find the pages containing the
 information generated by autogsdoc one has to scoure the site, even though
 reference documentation should be easy to find.  A link to the reference
 documentation shouuld appear on the main page instead of a link on a page
 form the sidebar at the bottom on the wiki page.

I agree that better links would be good from the website/wiki ... but bear
in mind that you are talking about developer api documentation here ... the
reader is normally expected to have this documentation locally on their own
machine.

So then does GS provide documentation as part of the GS packages, because i
installed it using the debian packages, and all I see are frameworks PM and
Gorm. If it is expected, is it so?


-- 
View this message in context: 
http://old.nabble.com/GNUStep-Documentation%E2%80%93-General-Improvements-tp32394188p32403512.html
Sent from the GNUstep - General mailing list archive at Nabble.com.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUStep Documentation– General Improvements

[Riccardo Mottola]

BTS wrote:



On 4 Sep 2011, at 01:31, BTS wrote:

   

There are a number of things that concern me about the manner in which
GNUStep is doccumented.

1. The first of which is that in order to find the pages containing the
information generated by autogsdoc one has to scoure the site, even though
reference documentation should be easy to find.  A link to the reference
documentation shouuld appear on the main page instead of a link on a page
form the sidebar at the bottom on the wiki page.
 

I agree that better links would be good from the website/wiki ... but bear
in mind that you are talking about developer api documentation here ... the
reader is normally expected to have this documentation locally on their own
machine.

So then does GS provide documentation as part of the GS packages, because i
installed it using the debian packages, and all I see are frameworks PM and
Gorm. If it is expected, is it so?
   
How did you install gnustep? I don't know how each distribution installs 
gnustep core packages. Perhaps a separate dev or documentation 
package? Both Foundation (base) and AppKit (gui) . make install inside 
their Documentation will install it.


Riccardo

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUStep Documentation– General Improvements

[Eric Wasylishen]

Hi,

 On 4 Sep 2011, at 01:31, BTS wrote:
 
 
 There are a number of things that concern me about the manner in which
 GNUStep is doccumented.
 
 1. The first of which is that in order to find the pages containing the
 information generated by autogsdoc one has to scoure the site, even though
 reference documentation should be easy to find.  A link to the reference
 documentation shouuld appear on the main page instead of a link on a page
 form the sidebar at the bottom on the wiki page.
 
 I agree that better links would be good from the website/wiki ... but bear
 in mind that you are talking about developer api documentation here ... the
 reader is normally expected to have this documentation locally on their own
 machine.
 
 So then does GS provide documentation as part of the GS packages, because i
 installed it using the debian packages, and all I see are frameworks PM and
 Gorm. If it is expected, is it so?
 
It looks like the gnustep-core-doc package will install the documentation 
packages on debian:
http://packages.debian.org/sid/gnustep-core-doc

-Eric
___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

GNUStep Documentation– General Improvements

[BTS]

There are a number of things that concern me about the manner in which
GNUStep is doccumented.

1. The first of which is that in order to find the pages containing the
information generated by autogsdoc one has to scoure the site, even though
reference documentation should be easy to find.  A link to the reference
documentation shouuld appear on the main page instead of a link on a page
form the sidebar at the bottom on the wiki page.

2. GNUStep uses it's own proprietary documentation genrator when perfectly
good Objective-C document generators such as Doxygene are available, and
also produce less bland more readably, clean and easily navigatable
documentation.  These doccument generators also have multiple output
formats.

3.  Required delegate methods should be indicated by differently colored
headers and anchor links.

4.  The example program page does not contain the sample code from the
sample programs, only their .app packages, this is generally a good demo,
but not helpful from a prgramming prespective.

5.  The GNUStep documentation does not reference sample code– even
referencing apple sample code would be useful, though optimally apple sample
code should be tested using GS APIs

If you agree and think things should change or you think I am in error feel
free to post your thoughts.  Making documentation easily readible, and
providing useful samples should be a priority in order to attract
developpers to the GNUStep platform.
-- 
View this message in context: 
http://old.nabble.com/GNUStep-Documentation%E2%80%93-General-Improvements-tp32394188p32394188.html
Sent from the GNUstep - General mailing list archive at Nabble.com.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUStep Documentation– General Improvements

[Gregory Casamento]

Just a few thoughts...  my comments follow in-line

On Sat, Sep 3, 2011 at 8:31 PM, BTS awi...@burningthumb.com wrote:

 There are a number of things that concern me about the manner in which
 GNUStep is doccumented.

 1. The first of which is that in order to find the pages containing the
 information generated by autogsdoc one has to scoure the site, even though
 reference documentation should be easy to find.  A link to the reference
 documentation shouuld appear on the main page instead of a link on a page
 form the sidebar at the bottom on the wiki page.

Absolutely true.   The documentation should be more readily available.

 2. GNUStep uses it's own proprietary documentation genrator when perfectly
 good Objective-C document generators such as Doxygene are available, and
 also produce less bland more readably, clean and easily navigatable
 documentation.  These doccument generators also have multiple output
 formats.

The reason for this is because GNUstep had this document generator
before Doxygene existed.   In fact there was some debate when Doxygene
first came out whether we should switch to it.   I believe we should
re-examine this possibility now if possible.   autogsdoc is a useful
tool, but it would also be nice to see if Doxygene could be used, if
it's not too much work to make this happen.

 3.  Required delegate methods should be indicated by differently colored
 headers and anchor links.

I agree.   This would be helpful.

 4.  The example program page does not contain the sample code from the
 sample programs, only their .app packages, this is generally a good demo,
 but not helpful from a prgramming prespective.

This also would be helpful.

 5.  The GNUStep documentation does not reference sample code– even
 referencing apple sample code would be useful, though optimally apple sample
 code should be tested using GS APIs

Yes, indeed.

 If you agree and think things should change or you think I am in error feel
 free to post your thoughts.  Making documentation easily readible, and
 providing useful samples should be a priority in order to attract
 developpers to the GNUStep platform.

GC

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

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUStep Documentation– General Improvements

[Richard Frith-Macdonald]

On 4 Sep 2011, at 01:31, BTS wrote:

 
 There are a number of things that concern me about the manner in which
 GNUStep is doccumented.
 
 1. The first of which is that in order to find the pages containing the
 information generated by autogsdoc one has to scoure the site, even though
 reference documentation should be easy to find.  A link to the reference
 documentation shouuld appear on the main page instead of a link on a page
 form the sidebar at the bottom on the wiki page.

I agree that better links would be good from the website/wiki ... but bear in 
mind that you are talking about developer api documentation here ... the reader 
is normally expected to have this documentation locally on their own machine.

 2. GNUStep uses it's own proprietary documentation genrator

Actually, it's a non-proprietory, open format and *free* tool usable by anyone, 
but it was designed for ObjC/GNustep.

 when perfectly
 good Objective-C document generators such as Doxygene are available,

But they weren't when the original markup language was designed (1997).  I 
think the gnustep documentation markup language pre-dates Doxygen, and while I 
agree that Doxygen's presentation is now much better, the autogsdoc stuff still 
has advantages (not least of which is the fact that you can install gnustep and 
generate the documentation without needing an external package).

 and
 also produce less bland more readably, clean and easily navigatable
 documentation.  These doccument generators also have multiple output
 formats.

autogsdoc is designed that way too (a big part of the reason the original 
markup language was done as xml was to facilitate the use of technologies like 
xslt to produce different output formats) ... but nobody's bothered to 
implement concrete formats.
It would be good to improve this (or adopt some format like Doxygen, if someone 
would volunteer to change all the source/headers/makefiles and add any missing 
features to Doxygen).

 3.  Required delegate methods should be indicated by differently colored
 headers and anchor links.

I'm not sure about that (generally I dislike a proliferation of different link 
colors), but it might be worth doing something to identify delegate methods.

 4.  The example program page does not contain the sample code from the
 sample programs, only their .app packages, this is generally a good demo,
 but not helpful from a prgramming prespective.
 
 5.  The GNUStep documentation does not reference sample code– even
 referencing apple sample code would be useful, though optimally apple sample
 code should be tested using GS APIs
 
 If you agree and think things should change or you think I am in error feel
 free to post your thoughts.  Making documentation easily readible, and
 providing useful samples should be a priority in order to attract
 developpers to the GNUStep platform.

Yes, we are constantly looking for someone to volunteer to improve 
documentation.


___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUStep Documentation– General Improvements

[Riccardo Mottola]

Hi,

1. The first of which is that in order to find the pages containing the
information generated by autogsdoc one has to scoure the site, even though
reference documentation should be easy to find.  A link to the reference
documentation shouuld appear on the main page instead of a link on a page
form the sidebar at the bottom on the wiki page.
   
the reference documentation is directly available form the site without 
going to the wiki. To be certain, it is available there too.
On the main page, select developers, which sounds pretty reasonable, 
on the side bar. on that page Manual and documentation should be 
pretty evident.


Using a search engine ( tried bing) for gnustep base reference yields 
the index as first result.


I personally find it very useful to install the documentation on my 
local HDD. Just make install inside documentation of base, gui, back.

2. GNUStep uses it's own proprietary documentation genrator when perfectly
good Objective-C document generators such as Doxygene are available, and
also produce less bland more readably, clean and easily navigatable
documentation.  These doccument generators also have multiple output
formats.
   
I think your own generator is quite good, it has no additional 
dependencies than gnustep itsels and writing comments for it is not that 
difficult.



3.  Required delegate methods should be indicated by differently colored
headers and anchor links.
   

could be a good idea.

4.  The example program page does not contain the sample code from the
sample programs, only their .app packages, this is generally a good demo,
but not helpful from a prgramming prespective.

   

What do you refer to? the gnustep examples contain full source code.


If you agree and think things should change or you think I am in error feel
free to post your thoughts.  Making documentation easily readible, and
providing useful samples should be a priority in order to attract
developpers to the GNUStep platform.
   

Agreed. In fact what is most disturbing for is that it is incomplete.

Riccardo

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep

Re: GNUStep Documentation– General Improvements

[Riccardo Mottola]

Hi

1. The first of which is that in order to find the pages containing the
information generated by autogsdoc one has to scoure the site, even though
reference documentation should be easy to find.  A link to the reference
documentation shouuld appear on the main page instead of a link on a page
form the sidebar at the bottom on the wiki page.
 

I agree that better links would be good from the website/wiki ... but bear in 
mind that you are talking about developer api documentation here ... the reader 
is normally expected to have this documentation locally on their own machine.

   
Two clicks from the main page is not *that* bad for a developer 
reference. I end up bookmarking it anyway...



2. GNUStep uses it's own proprietary documentation genrator
 

Actually, it's a non-proprietory, open format and *free* tool usable by anyone, 
but it was designed for ObjC/GNustep.

   
exactly. it is open as other generators too, it just didn't spread as 
others because it is geared to obj-c and our own needs.


I do use it to document several (obj-c) projects easily. Definitively 
not closed.

when perfectly
good Objective-C document generators such as Doxygene are available,
 

But they weren't when the original markup language was designed (1997).  I 
think the gnustep documentation markup language pre-dates Doxygen, and while I 
agree that Doxygen's presentation is now much better, the autogsdoc stuff still 
has advantages (not least of which is the fact that you can install gnustep and 
generate the documentation without needing an external package).

   

Not a small disadvantage.

and
also produce less bland more readably, clean and easily navigatable
documentation.  These doccument generators also have multiple output
formats.
 

autogsdoc is designed that way too (a big part of the reason the original 
markup language was done as xml was to facilitate the use of technologies like 
xslt to produce different output formats) ... but nobody's bothered to 
implement concrete formats.
It would be good to improve this (or adopt some format like Doxygen, if someone 
would volunteer to change all the source/headers/makefiles and add any missing 
features to Doxygen).

   
I like its current frame-based HTML output quite a bit. it is easily 
browseable. Writing a TEX backend would be nice, to eventually create a 
printable (and/or PDF) reference to the APIs, but our descriptions are 
anyway not yet that good to make it interesting

3.  Required delegate methods should be indicated by differently colored
headers and anchor links.
 

I'm not sure about that (generally I dislike a proliferation of different link 
colors), but it might be worth doing something to identify delegate methods.

   
Well, they could be marked / grouped... put in italic style or be 
referenced at the top in a list... just throwing in some ideas.


Riccardo

___
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep