Re: Hi, I'm back

[Riccardo]

Hello,
On Wednesday, May 18, 2005, at 06:40 PM, David Lázaro Saz wrote:
I'm back.  After five odd years away from GNUstep development I can  
return contributing again.  My circumstances have changed a lot,  
obviously, from the beginnings of 2000.  I'm older and all that.   I've 
been a professional developer all this years, mainly in  
commercial/proprietary code bases.
Nice! it is good to get some experienced people back here. You seem to 
have left a couple of months before I got seriously interested in 
gnustep. I am currently not involved in the development of gnustep 
itself, I develop FOSS applications with it. But lately I contribute to 
GAP (gnustep application project) and anyway development and use 
uncovers always questions, bugs, things to get improved and this is my 
contact with the developer world.


I have personal goals for this porting effort that could be at odds  
with the current design of the GNUstep GUI library and parts of  
foundation so I'd like to discuss my ideas with the people that are  
now actively in charge of the Windows parts of the code.  Drop me a  
message and I'll tell you what are my impressions or contact me  
through AIM at this e-mail address (my time zone is GMT+1, Europe/ 
Madrid, mind you).
Well, this is a good place to discuss public things and then we always 
have #gnustep on irc.freenode.org which is a nice place to chat too, 
although lately many "core" developers are busy or absent.

Adding a little bit of detail to the picture, the main goal is for  
this app to be completely integrated with the Windows look and feel.   
I've developed some tests libraries in a variety of languages: C, C+ +, 
Ruby bindings, you name it.  The end result is that there are some  
things that I didn't think that could be done that are, well, doable  
and working on Windows.  Things like activating XP theme support from  
a DLL dynamically that I haven't seen done on other GUI libraries.   
That was developed some months ago.
Well, if you already use EO, you don't use a native widget system, but a 
very well done theme Although I initially disliked this approach I now 
appreciate it more and think this is the way to go. It won't be probably 
be too difficult to make a NT4 like theme and one that looks like that 
rubber-candy look of XP.

I'm quite new in the window-side of GNUstep, I don't use personally 
windows, but lately I found interest in gnustep on windows in different 
occasions and for different reasons. A good gnustep on windows would be 
a very fine thing.

AFAIK, the current route is to work on MiniGW and use a native backendo 
on GDI. This certainly is the besto route to go to achieve maximum 
performance and integration. It will also ease deployment of gnustep 
applications on windows.
EO on the other hand took originally a Cygwin approac. I think that 
could be a good way to pursue too, for two reasons:
- it could be easier to have it working, since cygwin is much more 
unix-like and the backend could for example still work on X11
- some applications will need quite some adjustments to work on minigw, 
while probably you could have more luck on Cygwin.

So cygwin could not be only a temporary relief, but it could remain in 
the future also as "intermediate porting step".

To be honest my first and only attempt to build gnustep on cygwin failed 
miserably during the compilation of -base due to linker problems. The 
library archive files contain multiple entries with the same name and 
this confuses the linker. This is probably a limitation of the 
underlying .dll system, but I am really guessing in the dark here, my 
windows knowledge is a boundary of 0.

Unfortunately I had no time to report my problems and to have a further 
look at them.

Then I looked into how that could be integrated in our current apps.   
Looked through the active cross platform, open source, toolkit  efforts 
without success.  After everything has been examined and  reexamined I 
think that the easiest path, taking into account my  experience, is to 
get the GNUstep code base and bend it as needed to  accept this.  That 
way I will get what I need and maybe other people  can put that to good 
use, too.
Of course no one wil stop you to "bend" existing code to your needs, but 
maybe you may want to have a look at what already exists and what 
possibly the mainstream solutions are and will be, that could help you 
to reuse as much as possible of the existing and future work in 
"official" gnustep, but also to be able to commit back most of your work 
and help gnustep itself.

My main desktop/personal OS is OS X now and I've got a machine  
available that boots to NEXTSTEP 3.3 so if someone needs something  
related to that (testing, some questions answered, screenshots, for  
example) drop me a line too.
I too have as main box a 10.2 machine, but I still have a 10.1 machine 
from which I am typing. But maybe more interesting, I have a set of 
odder and less common systems running a variety

[Gnustep-cvs] GNUstep Testfarm Results

[Adam Fedor]

Test results for GNUstep as of Thu May 19 06:34:11 EDT 2005
If a particular system failed compilation, the logs for that system will
be placed at ftp://ftp.gnustep.org/pub/testfarm

If you would like to add your machine to this list, set up a cron job
(make sure you set up your PATH and other environment variables correctly)
to run the Startup/scripts/test-gnustep script (see the script comments 
for more info).

Success Compile i386-unknown-netbsdelf2.0.2 Thu May 19 03:58:10 CEST 2005
Success Compile powerpc-apple-darwin7.9.0 Thu May 19 04:25:22 MDT 2005
Success Compile sparc-sun-solaris2.7 Thu May 19 02:08:10 EDT 2005
Success Compile sparc64-unknown-netbsd2.0.2 Thu May 19 03:19:02 CEST 2005

Re: [Gnustep-cvs] gnustep/core/back Headers/xlib/XGGState.h Sourc...

[Fred Kiefer]

Adrian Robert wrote:
CVSROOT:/cvsroot/gnustep
Module name:gnustep
Branch: 
Changes by: Adrian Robert <[EMAIL PROTECTED]> 05/05/12 13:41:58
Modified files:
	core/back/Headers/xlib: XGGState.h 
	core/back/Source/xlib: XGGState.m GSXftFontInfo.m 

Log message:
cache Xft draw state in XGGState and use this to speed glyph rendering 
in GSXftFontInfo
There seems to be a small problem with these XFT support changes. The 
auto-configuration has a couple of XFT related setting, the ones of 
interest here are HAVE_XFT and HAVE_LIBXFT. Now the new code uses the 
later to flag areas which should only be included if XFT is present. But 
this seems to be a flag left over from a very old version, the 
configuration currently sets the first one if XFT is found. At least 
this is the case for me. At the moment I am not able to compile the xlib 
backend cleanly because of this. My suggestion is to replace all usage 
of HAVE_LIBXFT in XGGState.m and XGGState.h with HAVE_XFT.

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

[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSImageCell.m

[Fred Kiefer]

CVSROOT:/cvsroot/gnustep
Module name:gnustep
Branch: 
Changes by: Fred Kiefer <[EMAIL PROTECTED]> 05/05/19 11:45:54

Modified files:
core/gui   : ChangeLog 
core/gui/Source: NSImageCell.m 

Log message:
Treat nil as image unsetting in setObjectValue:.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2521&tr2=1.2522&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSImageCell.m.diff?tr1=1.24&tr2=1.25&r1=text&r2=text

Re: [Gnustep-cvs] gnustep/core/back Headers/xlib/XGGState.h Sourc...

[Adrian Robert]

On May 19, 2005, at 7:37 AM, Fred Kiefer wrote:
Adrian Robert wrote:
CVSROOT:	/cvsroot/gnustep
Module name:	gnustep
Branch: 	
Changes by:	Adrian Robert <[EMAIL PROTECTED]>	05/05/12 13:41:58
Modified files:
	core/back/Headers/xlib: XGGState.h 	core/back/Source/xlib: 
XGGState.m GSXftFontInfo.m Log message:
	cache Xft draw state in XGGState and use this to speed glyph 
rendering in GSXftFontInfo
There seems to be a small problem with these XFT support changes. The 
auto-configuration has a couple of XFT related setting, the ones of 
interest here are HAVE_XFT and HAVE_LIBXFT. Now the new code uses the 
later to flag areas which should only be included if XFT is present. 
But this seems to be a flag left over from a very old version, the 
configuration currently sets the first one if XFT is found. At least 
this is the case for me. At the moment I am not able to compile the 
xlib backend cleanly because of this. My suggestion is to replace all 
usage of HAVE_LIBXFT in XGGState.m and XGGState.h with HAVE_XFT.
Oops, I had looked at this, but not closely enough I guess.  What I saw 
were a number of HAVE_LIBXXX #defines, including HAVE_LIBXFT, and then 
also the HAVE_XFT.  Because the former was consistent with several 
others, I thought HAVE_XFT was the odd man out and was added by mistake 
at some stage.  I had been planning to excise it later if no problems 
arose..

Now looking again I see that HAVE_LIBXFT occurs in 'configure' but not 
'configure.ac'..

We should get rid of one and stick with the other.  Are there any 
reasons to prefer XFT or LIBXFT?  Currently the LIBXXX pattern is used 
for Xmu and Xext, while the XXX pattern is used for GLX.

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

Re: [Gnustep-cvs] gnustep/core/back Headers/xlib/XGGState.h Sourc...

[Adam Fedor]

On May 19, 2005, at 8:31 AM, Adrian Robert wrote:
Oops, I had looked at this, but not closely enough I guess.  What I 
saw were a number of HAVE_LIBXXX #defines, including HAVE_LIBXFT, and 
then also the HAVE_XFT.  Because the former was consistent with 
several others, I thought HAVE_XFT was the odd man out and was added 
by mistake at some stage.  I had been planning to excise it later if 
no problems arose..

Now looking again I see that HAVE_LIBXFT occurs in 'configure' but not 
'configure.ac'..

We should get rid of one and stick with the other.  Are there any 
reasons to prefer XFT or LIBXFT?  Currently the LIBXXX pattern is used 
for Xmu and Xext, while the XXX pattern is used for GLX.


HAVE_LIBXXX is set automatically by autoconf/configure when you check 
to see if a lib exists. The HAVE_XXX pattern is used more often when 
you need to check several things in order to make sure something is 
supported.


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

Re: Hi, I'm back

[David Lázaro Saz]

On 19/05/2005, at 10:36, Riccardo wrote:
Nice! it is good to get some experienced people back here.
Thanks.
Well, this is a good place to discuss public things and then we  
always have #gnustep on irc.freenode.org which is a nice place to  
chat too, although lately many "core" developers are busy or absent.
Hey, thanks for the tip.  I tend to forget that IRC is available.
Well, if you already use EO, you don't use a native widget system,  
but a very well done theme Although I initially disliked this  
approach I now appreciate it more and think this is the way to go.  
It won't be probably be too difficult to make a NT4 like theme and  
one that looks like that rubber-candy look of XP.
Certainly possible.  Windows provides a theme drawing API for that  
support and the _classic_ look is specified completely in Microsoft  
Windows User Experience book.

AFAIK, the current route is to work on MiniGW and use a native  
backendo on GDI. This certainly is the besto route to go to achieve  
maximum performance and integration. It will also ease deployment  
of gnustep applications on windows.
EO on the other hand took originally a Cygwin approac.
I'm partial to the MinGW approach.  It requires less support from the  
environment.

Of course no one wil stop you to "bend" existing code to your  
needs, but maybe you may want to have a look at what already exists  
and what possibly the mainstream solutions are and will be, that  
could help you to reuse as much as possible of the existing and  
future work in "official" gnustep, but also to be able to commit  
back most of your work and help gnustep itself.
That is my idea too.  Maybe I didn't explain well myself but that was  
why I used _bend_ instead of, lets say, _break_.

Cheers,
David.

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

Windows port direction

[David Lázaro Saz]

Hi there,
Yesterday I promised to begin explaining what is that I would like  
GNUstep do on the Windows side.  That's what this message is about.

What I would like it to be?  The quick answer would be everything to  
everybody!  But as agreeable as that would be, it won't be a very  
clear goal. So let's begin defining those goals and explain the  
current situation as I see it.

First, I'd like to be capable of doing development both on Windows  
and on Mac OS X.  That's because I'm usually on-the-go and the only  
thing I have at hand is my PowerBook.  I've got the latest Virtual PC  
version installed and running but it is very slow for full  
recompiles.  Thanks God for incremental compilation, though.

During the last night I got the full MinGW toolchain working on Mac  
OS X.  Is there any reference for cross-compiling GNUstep to contrast  
what I am doing to see if I'm doing things right?  That way I can  
correct any bad behaviour that appears.  The only thing that I found  
was last July's responses from Nicola to this mailing list.

That's enough of what I'm doing right now.  Let's continue with the  
bigger picture.

GNUstep's mission statement says that its goal is to create a free,  
superior development environment based on OpenStep and some of  
Cocoa's advances, taking into account the finer points of the display  
model while remaining somewhat look and feel agnostic.  I agree  
completely with these goals.  My intentions are only to try to define  
some clearer goals for the Windows port so I can work with it in a  
production environment.

Production quality apps for Windows are somewhat vaguely defined by  
the Microsoft logo guidelines.  The technical part of those  
guidelines are specified on the Windows Logo Program for Windows at  
 (sorry,  
some of them are Microsoft Office documents).  I think that a  
successful development environment should provide almost everything  
covered on those guidelines automatically.  Granted that could mean a  
long time of development but I think that, technically, GNUstep can  
cover those and even more.

From the Designed for Windows XP spec v2.3, you can see that three  
areas are covered: Windows fundamentals, install/remove, and data and  
settings management.  I'll refer you to that spec for the details.

GNUstep still doesn't cover install/remove of specific applications  
but in the future I think that it should be.  Maybe a way to  
automatically generate installer packages (.msi) and merge modules of  
the core libraries for ease of deployment.  There's a lot to say  
about this but for I think that it should go to the back of the list.

In relation with Windows fundamentals, what I need and think that  
GNUstep should cover is support for the Microsoft Windows User  
Experience guidelines and what is called _visual styles_ in the  
Windows world.  Let's begin with the following list:

* Document the points where GNUstep doesn't respect the guidelines.   
Menus are, for example, currently in a NeXT-style panel while they  
should be on the top of each window.  The OpenStep API covers very  
well that case so it should not be difficult.

Adding support for system colours is another point.  I think that a  
complete list should be maintained somewhere.

The "classic" Windows theme is also specified in the user experience  
book.  That is nice and should make it an easy and achievable first  
target.

* The common dialog library should be used, too.  It should be easy  
to hook into that as the OpenStep API also was designed with that in  
mind, as with the menu system.

* Provide support for visual styles by dynamically hooking into the  
UxTheme API.  Or what is the same: make GNUstep aware of what version  
of Windows is it running on, and depending on that activate the  
visual styles-aware drawing code.  I know how to do that with the  
Win32 API, it should be straight to make GSDrawing use that.

* In relation with GDI I think that its support should be finished.   
Make transparency work, for example.

After that, I think that a wrapper for GDI+ should be developed to  
control it using GNUstep's display model.  It should be as easy as  
hooking with GDI or even more because that API supports floating  
point coordinates, colour spaces and more.  The only problem is that  
it is C++, but it should be wrapped with a C interface similar to  
Quartz and the DPS operators.  If it is easier, maybe that should be  
supported first.  I don't know what would be better.

* The defaults system in Windows should read and write to the defined  
locations for that.  Maybe GNUstep on Windows should support both.  I  
haven't made my mind on this point yet.

There are a lot more things to cover but I think that this should be  
enough for the first day, or even week to discuss.  I also hope that  
it is clear that I'm not talking about removing anything, only about  
adding support for Win

Re: Hi, I'm back

[Adam Fedor]

On May 18, 2005, at 4:11 PM, David Lázaro Saz wrote:
P.S.: Is it me or is this mailing list working _slowly_?
Well, spam on all the lists has gone up by a factor or 3 or 4 in the 
past few weeks...


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

[Gnustep-cvs] gnustep/dev-apps/Gorm ChangeLog

[Gregory John Casamento]

CVSROOT:/cvsroot/gnustep
Module name:gnustep
Branch: 
Changes by: Gregory John Casamento <[EMAIL PROTECTED]>  05/05/20 
04:04:40

Modified files:
dev-apps/Gorm  : ChangeLog 

Log message:
Corrected time.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/ChangeLog.diff?tr1=1.664&tr2=1.665&r1=text&r2=text

[Gnustep-cvs] gnustep/dev-apps/Gorm ChangeLog GormInfo.plist ...

[Gregory John Casamento]

CVSROOT:/cvsroot/gnustep
Module name:gnustep
Branch: 
Changes by: Gregory John Casamento <[EMAIL PROTECTED]>  05/05/20 
04:01:51

Modified files:
dev-apps/Gorm  : ChangeLog GormInfo.plist Version 
dev-apps/Gorm/Documentation: GNUmakefile news.texi 
dev-apps/Gorm/GormCore: GormFilePrefsManager.m 

Log message:
Committing release information.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/ChangeLog.diff?tr1=1.663&tr2=1.664&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/GormInfo.plist.diff?tr1=1.26&tr2=1.27&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Version.diff?tr1=1.20&tr2=1.21&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Documentation/GNUmakefile.diff?tr1=1.4&tr2=1.5&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/Documentation/news.texi.diff?tr1=1.19&tr2=1.20&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/GormCore/GormFilePrefsManager.m.diff?tr1=1.6&tr2=1.7&r1=text&r2=text

[Gnustep-cvs] gnustep/dev-apps/Gorm ANNOUNCE NEWS

[Gregory John Casamento]

CVSROOT:/cvsroot/gnustep
Module name:gnustep
Branch: 
Changes by: Gregory John Casamento <[EMAIL PROTECTED]>  05/05/20 
04:33:03

Modified files:
dev-apps/Gorm  : ANNOUNCE NEWS 

Log message:
Correction to announcement and install files.

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/ANNOUNCE.diff?tr1=1.16&tr2=1.17&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/Gorm/NEWS.diff?tr1=1.17&tr2=1.18&r1=text&r2=text