Re: Proposal to deprecate Xlib backend
On 12/28/06, Hubert Chan <[EMAIL PROTECTED]> wrote: On Thu, 28 Dec 2006 00:38:18 +0100, Guenther Noack <[EMAIL PROTECTED]> said: [...] > I could also imagine that a clear indication that xlib is deprecated > may help people outside the GNUstep project. For example when looking > at Etoile, there are at least the MultimediaKit and the > XWindowServerKit which directly talk to X11 (MMKit displays the > Mplayer window in a GNUstep window). For authors of projects like > these two, it may be very helpful to know that they won't have to > support xlib in the future. AFAIK, Etoile still needs to talk to X11 directly for those functions. They are mostly for things that the *Step API does not handle (e.g. switching desktops, embedding, etc.). I think people are talking about using X11 for drawing, not window and even handling in this case. So deprecating x11 backend does not affect the use of X11. Yen-Ju -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Test fro overridden method
Could somebody please verify that this method does what I expect it to do?
I need such a test within NSDocument. Here Apple takes special care that
if somebody has implemented the old interface methods for NSDocument in
a subclass, then these methods are actually called instead of the new
interface methods.
/*
* Private helper method to check, if the method given via the selector sel
* has been overridden in the current subclass.
*/
- (BOOL)_hasOverridden: (SEL)sel
{
// The actual signature is not important as we wont call the methods.
IMP meth1;
IMP meth2;
meth1 = [self methodForSelector: sel];
meth2 = [[NSDocument class] instanceMethodForSelector: sel];
return (meth1 != meth2);
}
If the code stays that simple, I might even make a macro of it.
Cheers,
Fred
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Making release of gui 1/13/2007
Gregory John Casamento schrieb: > > I would like to shoot for making a release of gui on 1/13/2007. > I am currently working on a rework of NSDocument to include all the new MacOS 10.4 methods. Should I try to get these changes in before the release or after it? These changes need to break backwards compatibility as loads of new ivars need to be added. You will have to recompile all applications using subclasses for NSDocument. As I plan to do similar breaking of backwards compatibility over the next few months, it might be worthwhile to group them together into one release. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
On Thu, 28 Dec 2006 00:38:18 +0100, Guenther Noack <[EMAIL PROTECTED]> said: [...] > I could also imagine that a clear indication that xlib is deprecated > may help people outside the GNUstep project. For example when looking > at Etoile, there are at least the MultimediaKit and the > XWindowServerKit which directly talk to X11 (MMKit displays the > Mplayer window in a GNUstep window). For authors of projects like > these two, it may be very helpful to know that they won't have to > support xlib in the future. AFAIK, Etoile still needs to talk to X11 directly for those functions. They are mostly for things that the *Step API does not handle (e.g. switching desktops, embedding, etc.). -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
drawing artifacts...
sorry this email has a ton of attachments...
while i'm fairly sure the attached patch isn't correct
it does get rid of any remaining artifacts caused by
cursor movement in NSTableView
but i have yet to see anywhere the code i modify
actually does anything, since by default table view
NSTextFieldCells don't draw their backround
(in between foo3 and 8 nothing seemed to happen... so
i didn't attach those)
you can see the progression of these artifacts,
and the before/after of my most recent patch committed
to back in the new/old.png's...
http://svn.gna.org/viewcvs/gnustep/libs/back/trunk/Source/x11/XGServerWindow.m?rev=24287&r1=24246&r2=24287
this was using back-art...
anyhow it'd be great to get rid of these artifacts
completely, but it seems better than it was...
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Index: Source/NSTableView.m
===
--- Source/NSTableView.m(revision 24288)
+++ Source/NSTableView.m(working copy)
@@ -3271,13 +3271,13 @@
// We really want the correct background color!
if ([_editedCell respondsToSelector: @selector(setBackgroundColor:)])
{
- [(NSTextFieldCell *)_editedCell setBackgroundColor: _backgroundColor];
+ [(NSTextFieldCell *)_editedCell setBackgroundColor: [NSColor
textBackgroundColor]];
}
else
{
- [t setBackgroundColor: _backgroundColor];
+ [t setBackgroundColor: [NSColor textBackgroundColor]];
}
-
+
// But of course the delegate can mess it up if it wants
[self _willDisplayCell: _editedCell
forTableColumn: tb
@@ -3299,7 +3299,8 @@
}
_textObject = [_editedCell setUpFieldEditorAttributes: t];
-
+ [_textObject setDrawsBackground:YES];
+
drawingRect = [self frameOfCellAtColumn: columnIndex row: rowIndex];
if (flag)
{
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Make Windows installers for each release...
Please let me know if you are interested to work on this project(win32 GNUstep by WiX). I mean win32 GNUstep MSI installer by WiX tool. tj _ Experience the magic of the holidays. Talk to Santa on Messenger. http://clk.atdmt.com/MSN/go/msnnkwme008001msn/direct/01/?href=http://imagine-windowslive.com/minisites/santabot/default.aspx?locale=en-us ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Make Windows installers for each release...
From: Richard Frith-Macdonald <[EMAIL PROTECTED]> To: Aaron G <[EMAIL PROTECTED]> CC: GNUstep Developers Subject: Re: Proposal: Make Windows installers for each release... Date: Thu, 28 Dec 2006 20:44:11 + On 28 Dec 2006, at 20:31, Aaron G wrote: As someone who would use this, I like the idea. I use OS X and Windows, and only use linux as a text-only vm, so It would be a great help to be able to install this. Right now I only use this as a hobby, but I could begin to help test things. If it wasnt a pain in the ass to install. On 12/28/06, Gregory John Casamento <[EMAIL PROTECTED]> wrote: Currently our release policy for windows has been a bit spotty.We seem to release a version for Windows sporadically. I'd like to shoot for having every release have a Windows installer available for it, if that's possible. Any thoughts on this? Inspired by T.J Yang, i was thinking of investigating the possibility of incorporating WiX support into gnustep-make (in the way that rpm support is currently built in) and perhaps his idea of TWW tolls later. If WiX support was in the make system, we could build windows install packages trivially ... which would be great. I think this is quite a long term goal to have GNUstep generate native package format. Currently we need to have a higher degree of automation(digitation) in the GNUstep development and distribution mechanism. A ready to run binary is much better than tar ball on ftp.gnu.org. Regarding to WiX and GNUstep, I believe current installer is using nullsoft for win32 packaging. I wish we can release a version of win32 GNUstep using WiX. so that the package source is in xml files that others can inherit,study and enhance easily. Last time I checked outWiX 2.x PMS, it require every file to have a UUID. and it was hard to include files under a sub directory. WiX 3.x is in beta but it has better support for subdirectory inclusion and auto UUID generation. Please let me know if you are interested to work on this project(win32 GNUstep by WiX). Regards tj _ Type your favorite song. Get a customized station. Try MSN Radio powered by Pandora. http://radio.msn.com/?icid=T002MSN03A07001 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Make Windows installers for each release...
On 28 Dec 2006, at 20:31, Aaron G wrote: As someone who would use this, I like the idea. I use OS X and Windows, and only use linux as a text-only vm, so It would be a great help to be able to install this. Right now I only use this as a hobby, but I could begin to help test things. If it wasnt a pain in the ass to install. On 12/28/06, Gregory John Casamento <[EMAIL PROTECTED]> wrote: Currently our release policy for windows has been a bit spotty. We seem to release a version for Windows sporadically. I'd like to shoot for having every release have a Windows installer available for it, if that's possible. Any thoughts on this? Inspired by T.J Yang, i was thinking of investigating the possibility of incorporating WiX support into gnustep-make (in the way that rpm support is currently built in) and perhaps his idea of TWW tolls later. If WiX support was in the make system, we could build windows install packages trivially ... which would be great. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Make Windows installers for each release...
As someone who would use this, I like the idea. I use OS X and Windows, and only use linux as a text-only vm, so It would be a great help to be able to install this. Right now I only use this as a hobby, but I could begin to help test things. If it wasnt a pain in the ass to install. On 12/28/06, Gregory John Casamento <[EMAIL PROTECTED]> wrote: Currently our release policy for windows has been a bit spotty. We seem to release a version for Windows sporadically. I'd like to shoot for having every release have a Windows installer available for it, if that's possible. Any thoughts on this? Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Making release of gui 1/13/2007
All, I would like to shoot for making a release of gui on 1/13/2007. Thanks, GJC -- Gregory Casamento ## GNUstep Chief Maintainer ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Proposal: Make Windows installers for each release...
Currently our release policy for windows has been a bit spotty. We seem to release a version for Windows sporadically. I'd like to shoot for having every release have a Windows installer available for it, if that's possible. Any thoughts on this? Later, GJC -- Gregory Casamento ## GNUstep Chief Maintainer ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Which GNUstep win32 installer is working ?
I like to put some efforts about TWW packaging for GNUStep win32. But I am having problem to install a working version that can have GNUstep apps run on windows screen (like Gorm.app or GStest.app). Here are installers I have tried in ftp://ftp.gnustep.org/pub/gnustep/binaries/windows/ 1. Install-GNUstep-Development-Environment-1.10.1-bin.exe 2. GNUstep-base-1.10.1-gui-0.9.4.exe. 3. GNUstep-base-1.11.1-gui-0.10.1-3.exe I remember I used be able to have 1. installed but now it ended with error message(my laptop has bad been upgraded to SP2 since). 2. one has following error message when I try to compile a test apps (Gorm.app). $ make rm -rf InterfaceBuilder ln -s GormLib InterfaceBuilder Making all in GormObjCHeaderParser... make[1]: Entering directory `/F/old/gorm-1.1.0/GormObjCHeaderParser' Making all for library libGormObjCHeaderParser... Creating derived_src... Compiling file NSScanner+OCHeaderParser.m ... Compiling file OCHeaderParser.m ... Compiling file OCIVar.m ... Compiling file OCIVarDecl.m ... Compiling file OCMethod.m ... Compiling file ParserFunctions.m ... Linking library libGormObjCHeaderParser ... c:\GNUstep\Development\msys\1.0\mingw\bin\dllwrap.exe: installation problem, cannot exec `gcc': Permission denied make[2]: *** [shared_obj/GormObjCHeaderParser.dll] Error 1 make[1]: *** [libGormObjCHeaderParser.all.library.variables] Error 2 make[1]: Leaving directory `/F/old/gorm-1.1.0/GormObjCHeaderParser' make: *** [internal-all] Error 2 [EMAIL PROTECTED] /F/old/gorm-1.1.0 $ 3. one has problem about "/etc/GNUstep.conf" can't be found. Can we have base-1.11.2-gui-0.10.2 deleted since it is empty ? Question is anyone got installer working for winxp sp2 ? Thanks T.J. Yang _ Get FREE Web site and company branded e-mail from Microsoft Office Live http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Minor release policy update
Appreciate for letting me back in ;) T.J. Yang From: Adam Fedor <[EMAIL PROTECTED]> To: "T.J. Yang" <[EMAIL PROTECTED]> CC: Richard Frith-Macdonald <[EMAIL PROTECTED]>, Developer GNUstep , gnustep-webmasters@gnu.org Subject: Re: Minor release policy update Date: Thu, 28 Dec 2006 10:43:03 -0700 On Dec 28, 2006, at 10:27 AM, T.J. Yang wrote: I have sent request to add my account "tjyang" to be able to edit wiki page two days ago. How long should I wait for the response ? I was just about to ask what your username was, since you didn't send that in the mail to webmasters... You should be set now. _ Your Hotmail address already works to sign into Windows Live Messenger! Get it now http://clk.atdmt.com/MSN/go/msnnkwme002001msn/direct/01/?href=http://get.live.com/messenger/overview ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Minor release policy update
On Dec 28, 2006, at 10:27 AM, T.J. Yang wrote: I have sent request to add my account "tjyang" to be able to edit wiki page two days ago. How long should I wait for the response ? I was just about to ask what your username was, since you didn't send that in the mail to webmasters... You should be set now. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Minor release policy update
I have sent request to add my account "tjyang" to be able to edit wiki page two days ago. How long should I wait for the response ? Thanks tj _ Type your favorite song. Get a customized station. Try MSN Radio powered by Pandora. http://radio.msn.com/?icid=T002MSN03A07001 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
Hi! On Mon, Dec 25, 2006 at 06:00:59PM +, Richard Frith-Macdonald wrote: > It seems reasonable to move away from it ... but Cairo is not ready > yet, and the art backend seems to have its own problems. My > impression is that art is a little better than xlib but harder to > maintain (code less clear etc). I'm taking it on trust (Fred's > judgment and yours) that Cairo is the way to go rather than improving > an older backend ... I don't have the graphics knowhow to make a good > judgment myself. I understand your concern that Cairo is not ready yet for production use. But isn't art stable enough? I haven't heard of people using or even promoting the use of xlib in a long time. > I think very little time is spent on maintaining either art or > xlib ... interaction with x window managers needing (and getting) > more attention than the actual xlib or art rendering code, so it's > not a big issue right now. > > However, we do need to make sure people don't waste time on > development work for multiple backends ... so we need a clear policy > for future development work (especially for any new volunteers). As a voluntary open source developer, I personally usually prefer implicitly understandable hints about how to write code over big developer documentation. Time is limited after all, and when programming in one's free time, people want to get to the nitty gritty fast. :-> For example, it's obvious that you shouldn't spend a lot of time on code which is located in a directory called 'deprecated'. But has everybody outside the GNUstep core team read the GNUstep developer documentation? I could also imagine that a clear indication that xlib is deprecated may help people outside the GNUstep project. For example when looking at Etoile, there are at least the MultimediaKit and the XWindowServerKit which directly talk to X11 (MMKit displays the Mplayer window in a GNUstep window). For authors of projects like these two, it may be very helpful to know that they won't have to support xlib in the future. But those are just my 2 cents. :-> -Guenther ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Minor release policy update
I have updated the release policy document on the wiki slightly ... http://wiki.gnustep.org/index.php/GNUstep_release_policy The idea is just to make the stable branches/releases more obvious by using the word 'stable' rather than the version numbers as the name for the branch. This also means we can more easily automate processes for the stable branch ... I've made a tiny start by adding a gnustep-make 'svn- bugfix' target to export a .tar.gz archive from the stable branch. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cocotron
On 28 Dec 2006, at 00:35, Tima Vaisburd wrote: I disagree that we should adopt the single platform approach ... my feeling is that what they have right is the idea that interface completeness is unnecessary if you have good enough feature coverage. So I think we should be concentrating on that 'good enough' feature coverage and making that easy for people to get started with. I'm certainly not arguing that we should not add new features, just that our priority should be delivering ease of use rather than completing the task of implementing the entire API. Ok, I happily agree with you. I tried to describe it as "feature completeness": maybe not all functions are implemented, but with those that are you can write everything you want. I wrote about sticking to Linux only because I was looking for a way to reduce the amount of work to be done until, say, "stage 1" is fully completed. But your suggestion is even better. Please note, though, that this task is harder to define - you need to deeply know the interface rather than go search for FIXME or NOT IMPLEMENTED. I do not have such understanding, for example. It's somebody like you (or just you :-) ) needs to say: here is a set of methods, we do them and nothing else. I don't have that knowledge either ... and I'm not sure anyone does. IMO the best way to find out what bits of the API still need to be implemented as a priority is to get people to join the project writing applications to do particular jobs, and somehow encourage those people to either fill in the missing bits they need or at least point them out as feature requests/bug reports ... but to have them involved somehow. I have a suspicion that people who find something they need missing just tend to quietly give up and go away, so that nobody else even knows about the problem ... or they perhaps raise the issue in a chatroom, where there is no record of it. We need such feedback to tell where to focus (though ideally we need patches to be contributed). In fact I wonder if the irc chatroom harms the project ... my impression (from lurking on irc a bit recently) is that most of the people who hang out there are not gnustep developers ... ie they are people who don't want to contribute to the project, but are interested in using gnustep in other things. So asking for help in the chatroom is quite likely to mean that anything said does not actually get through to anyone working on gnustep! It's also as likely to get a response griping about gnustep as it is to get something helpful. So it seems the chatroom gives us bad publicity and blocks feedback from getting to us! I don't know what we can do about that though. I'm inclined to say that core developers should not be proactively implementing missing parts of the API at all ... but should be concentrating on the ease of use and user appeal issues and only work on missing API as a response to a specific bug report or feature request from a user. Of course, sometimes ease of use work implies large scale changes including implementing missing API. For instance ... even though I don't know the Apple CoreGraphics API at all, I think we should be changing the gui/backend interface to use that for drawing rather than the old DPS methods. It's an issue which ought to make a real usability difference for any MacOS-X developer looking to use GNUstep who is doing any drawing into views at all. However, this is lower priority than other usability issues. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
