[Gnustep-cvs] gnustep/dev-apps/test/Testsuite ChangeLog base/...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: David Ayers [EMAIL PROTECTED] 05/11/27 10:56:14 Modified files: dev-apps/test/Testsuite: ChangeLog Added files: dev-apps/test/Testsuite/base/NSFileHandle: basic.m general.m Log message: * base/NSFileHandle/basic.m: New test. * base/NSFileHandle/general.m: Ditto. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/test/Testsuite/ChangeLog.diff?tr1=1.25tr2=1.26r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/test/Testsuite/base/NSFileHandle/basic.m?rev=1.1 http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/dev-apps/test/Testsuite/base/NSFileHandle/general.m?rev=1.1
Re: Notification once a minute - for a clock...
Quoting Jiva DeVoe [EMAIL PROTECTED]:
So I'm sorta hacking on WildMenus this weekend, and have implemented
a primitive clock in the menubar... I'm wondering what's the best way
to get my clock to redraw once a minute? Obviously the menu code
itself gets linked into each application, so having 20 applications
all launching their own little background timers to update the
menubar clock sounds kinda cruddy. What would be the best way to do
this? I imagine some kind of NSNotification but that also seems cruddy.
(ps: For those who want said functionality - I have been sending
patches to Michael Hanni, the WildMenus maintainer, so look for a
release from him eventually.)
--
Jiva DeVoe
http://www.devoesquared.com
PowerCard - Intuitive Project Management for Mac OS X
This in fact isn't such a big problem. But to get the max efficiency out of it
do it like this:
// if we're not the currently displayed app this method immediately returns
- (void) invokedOnceAMinute
{
if ([NSApp isActive])
{
[self updateClockDisplay];
}
}
// update the clock's display in case it hasn't been updated in the mean time
- (void) appDidBecomeActive
{
[self updateClockDisplay];
}
Regards
--
Saso
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Window server and System UI Process (Was: Re: Notification once a minute - for a clock...)
Hi, On 26.11.2005, at 23:06, Jiva DeVoe wrote: So I'm sorta hacking on WildMenus this weekend, and have implemented a primitive clock in the menubar... I'm wondering what's the best way to get my clock to redraw once a minute? Obviously the menu code itself gets linked into each application, so having 20 applications all launching their own little background timers to update the menubar clock sounds kinda cruddy. What would be the best way to do this? I imagine some kind of NSNotification but that also seems cruddy. (ps: For those who want said functionality - I have been sending patches to Michael Hanni, the WildMenus maintainer, so look for a release from him eventually.) Just for inspiration, how it looks on OS X. Here is a screenshot from Quartz debug - an application that can show all windows and their properties: http://stefan.agentfarms.net/Download/GNUstep/Trash/Quartz%20window% 20list.png Main menu (horizontal) is window number WID=5 owned by process called WindowsServer. That means that the menu is not drawn nor owned by any application, applications just provide menu contents that is passed to the menu owner - window server. The status bar is owned by damon/process called system UI server. WID 3a is the status bar (see NSStatusItem class) and WID 39 is the Spotlight magnifier icon. Having those two processes separated from applications can simplify lots of things, including custom menu orientation, addition of shared menu entries across applications (like apple has apple menu, or menu with debug or scripting actions)... Stefan Urbanek -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep ROADMAP
On Nov 26, 2005, at 11:23 AM, Adrian Robert wrote: GNUstep 1.1 Integrate camaelon into gui ... I think this should be in 1.0 as a matter of practicality ... as far as I can see, this is an easily achievable target, so why not do it soon. I really think this needs to go into 1.0. Judging by the amount of discussion themes ALWAYS get whenever there is ANY external publicity about GNUstep, I think initial reception will be far better if we can just say, "download and switch on this theme" instead of "someday we'll have Camealon in GNUstep". Let's not be impatient for the 1.0 release and then have lots of people dismissing it with "great, but too 80's for me".. Integration of WildMenus ... I haven't looked at this, so i don't know, but seems reasonable. This on the other hand, we rarely hear about on the lists, so I think it's a much lower priority than Camaelon. I'm new here, and obviously, much genuflection to everyone involved... but I just wanted to say from an outsider's standpoint, camaelon IMO is an absolute requirement to have in 1.0. I'm sure there's lots of arguments on why not to do it, but from an outsider standpoint, it's a must-have.WRT WildMenus - WildMenus is useful if one is coming from a Mac, and wants Mac style menus... I'd argue that alone makes it worthwhile - but the thing that would make it really killer would be if it could also attach the menus to whatever main window there is currently (ala Windows etc) to make GNUstep apps not look like the "odd man out" when mixing on other window managers/desktops. I know this is not a trivial task. WildMenus - though cool, and I obviously use it myself, I think is not vital for a 1.0. 1.1 sure... when it gets a nice overhaul with a clock and little status applets like the mac menu, or if it gets the ability to do windows-like menus... (:: sounds of screams from GNUstep purists ::) -- Jiva DeVoe http://www.devoesquared.com PowerCard - Intuitive Project Management for Mac OS X ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep ROADMAP
Hi Gregory, Gregory John Casamento wrote: --- Fred Kiefer [EMAIL PROTECTED] wrote: Gregory John Casamento wrote: If you are a maintainer, please make any changes for your section that you deem appropriate. as far as I know we currently don't have a maintainer for GUI, so we all should comment on that part. And some of us already did in previous mail exchanges. I remember two points from my mail (yes one tends to remember ones own entries best) which are not addressed by your list. One being the stable memory layout of the GUI classes. Why would we call a release 1.0 if it does not garranty some sort of stable interface? Could you elaborate on this point? Sorry, I should have been more explicit. I was refering to missing or obsolete ivars for the GUI classes. Have a look at NSResponder, here you find a bunch of boolean variables, most of them only used in the NSView subclasses. We could decide now to move these ivars to NSView, but we should not do so after release 1.0. On the other hand are we missing quite some ivars for NSCell, if we want to get fully compatible with Cocoa. Richard posted some ideas on how we could still extend classes after the 1.0 relase, but we need to prepare them now. The other being the problems with the matrix classes. If we want a complete coding here, we will probably have to wait for GNUstep GUI 1.0 for another year, or even more. Is this what you want? No. I would rather have a 1.0 release sooner rather than later. All multiple cell classes are only partial usable, they work for simple exmaples, but when put in general use they seem to fail. Could you go ahead and add details of what needs to be done to the cell classes to the Roadmap where you think it needs to be? I don't have Wiki write access, yes, I should just register. The problem itself is obvious, just by looking into the bug database, or following the mailing list. The classes NSMatrix, NSBrowser, NSTableView and NSOutlineView are usable, but not much more. We may be able to improve them, but I don't see a complete implementation for the 1.0 release. Removing classes? Which classes are you talking about. At least after Richards question you should have given an example. There are classes in GUI that have currently no actual benefit, like NSMovie, but we will surely implement them later on. Do you want to remove these classes? I'm only advocating removal of shell classes which currently exist as placeholders for things that are entirely unimplemented. I'm not saying that we should remove a class that has an incomplete implementation. In my view, if we're not going to make a class somewhat usable (i.e. even a skeletal/simply implementation), then we should remove it until the next release. This is because it's confusing to the developer who ports an app. If the header is there, I'll naturally assume that the class is available. If it's not, then I know it's yet to be implemented. NSMovieView and NSMovie, as you pointed out, are excellent examples of this. I'm not sure if anyone is going to have the time to do it before we want to make a 1.0 release. I had a similar discussion with Nicola almost five years ago. At that time it was about what unimplemened methods should do, raise a condiontion or silently ignore the fact that there is no code. We came to the conclusion that outputting a warning would be best. When we remove these classes any application that refers to object of these classes, even if they are not critical to the overall behaviour of the application, wont compile with GNUstep. If we leave the classes in, but put warning messages (printed only once) into the empty methods, these application work, with minimal functionality missing. That's why I used NSMovie as an example. You surely wont be able to implement a movie player with GNUstep at the time being, but if your application sport only a gimmick movie in the about box, it should still work with GNUstep, without displaying the movie of course. Or what if I wanted to contribute a simple minded implementation of NSearchField in the next weeks? Would we drop that class again, as the implementation would not be complete? So long as the class works on some level, it's okay to leave it in. I'm referring mainly to those classes which are in GNUstep which are simply shells awaiting some kind of implementation and do not work at all. works on some level, what if I think that not raising an exception is already some sort of working? When I started with GNUstep, most of the GUI classes where empty declarations, which needed filling out and that was what I did. If we would have removed all classes without implementation at that time, GNUstep would still be rather empty. I really would prefer warning messages at runtime from removing classes as a whole. Will it be a problem that some applications will compile, but later fail to run correctly? I don't think so, as long as we
Re: GNUstep ROADMAP
Fred, --- Fred Kiefer [EMAIL PROTECTED] wrote: Hi Gregory, Gregory John Casamento wrote: --- Fred Kiefer [EMAIL PROTECTED] wrote: Gregory John Casamento wrote: If you are a maintainer, please make any changes for your section that you deem appropriate. as far as I know we currently don't have a maintainer for GUI, so we all should comment on that part. And some of us already did in previous mail exchanges. I remember two points from my mail (yes one tends to remember ones own entries best) which are not addressed by your list. One being the stable memory layout of the GUI classes. Why would we call a release 1.0 if it does not garranty some sort of stable interface? Could you elaborate on this point? Sorry, I should have been more explicit. I was refering to missing or obsolete ivars for the GUI classes. Have a look at NSResponder, here you find a bunch of boolean variables, most of them only used in the NSView subclasses. We could decide now to move these ivars to NSView, but we should not do so after release 1.0. On the other hand are we missing quite some ivars for NSCell, if we want to get fully compatible with Cocoa. Richard posted some ideas on how we could still extend classes after the 1.0 relase, but we need to prepare them now. I see what you mean. Our ivar layout should be stable before we release a 1.0, I agree. The other being the problems with the matrix classes. If we want a complete coding here, we will probably have to wait for GNUstep GUI 1.0 for another year, or even more. Is this what you want? No. I would rather have a 1.0 release sooner rather than later. All multiple cell classes are only partial usable, they work for simple exmaples, but when put in general use they seem to fail. Could you go ahead and add details of what needs to be done to the cell classes to the Roadmap where you think it needs to be? I don't have Wiki write access, yes, I should just register. The problem itself is obvious, just by looking into the bug database, or following the mailing list. The classes NSMatrix, NSBrowser, NSTableView and NSOutlineView are usable, but not much more. We may be able to improve them, but I don't see a complete implementation for the 1.0 release. Okay. Removing classes? Which classes are you talking about. At least after Richards question you should have given an example. There are classes in GUI that have currently no actual benefit, like NSMovie, but we will surely implement them later on. Do you want to remove these classes? I'm only advocating removal of shell classes which currently exist as placeholders for things that are entirely unimplemented. I'm not saying that we should remove a class that has an incomplete implementation. In my view, if we're not going to make a class somewhat usable (i.e. even a skeletal/simply implementation), then we should remove it until the next release. This is because it's confusing to the developer who ports an app. If the header is there, I'll naturally assume that the class is available. If it's not, then I know it's yet to be implemented. NSMovieView and NSMovie, as you pointed out, are excellent examples of this. I'm not sure if anyone is going to have the time to do it before we want to make a 1.0 release. I had a similar discussion with Nicola almost five years ago. At that time it was about what unimplemened methods should do, raise a condiontion or silently ignore the fact that there is no code. We came to the conclusion that outputting a warning would be best. When we remove these classes any application that refers to object of these classes, even if they are not critical to the overall behaviour of the application, wont compile with GNUstep. If we leave the classes in, but put warning messages (printed only once) into the empty methods, these application work, with minimal functionality missing. That's why I used NSMovie as an example. You surely wont be able to implement a movie player with GNUstep at the time being, but if your application sport only a gimmick movie in the about box, it should still work with GNUstep, without displaying the movie of course. But we're being inconsistent. What if my application uses NSInputStream, which currently is not implemented in GNUstep? Should it not work by the same token as above? Or what if I wanted to contribute a simple minded implementation of NSearchField in the next weeks? Would we drop that class again, as the implementation would not be complete? So long as the class works on some level, it's okay to leave it in. I'm referring mainly to those classes which are in GNUstep which are simply shells awaiting some kind of implementation and do not work at all. works on some level, what if I think that not raising an exception is already some sort of working? I believe you know what I
Re: GNUstep ROADMAP
On 28 Nov 2005, at 02:17, Gregory John Casamento wrote: Fred, --- Fred Kiefer [EMAIL PROTECTED] wrote: When I started with GNUstep, most of the GUI classes where empty declarations, which needed filling out and that was what I did. Having empty declarations is okay for something that's in beta, however, for a 1.0, I'm not sure that we should include those classes which are simply empty declarations. If we would have removed all classes without implementation at that time, GNUstep would still be rather empty. I really would prefer warning messages at runtime from removing classes as a whole. Will it be a problem that some applications will compile, but later fail to run correctly? I don't think so, as long as we output honest warnings about missing code. Having a method not implemented macro in some GNUstep header file could help here. (What about using GSOnceMLog for that?) I really would rather save the developer time and expense of porting an application only to have it say NSException: This functionality is not currently implemented at runtime. If it were me, I would be supremely frustrated that I spent hours porting something only for it to fail at runtime. I'm with Fred on this one ... certainly on partially implemented classes, but also (though less strongly) on completely empty ones. I think there is absolutely zero risk of someone wasting loads of time porting only to find something critical missing... as long as our documentation does not tell lies (and little chance of it even then). We do need to make sure that the documentation is up to date, so it says which methods of which classes are unimplemented. IMO partially implemented classes tell people that there is some hope of the classes being done in future ... or at least that the GNUstep project would look favourably upon people contributing in those areas. In fact it would probably be good if unimplemented methods actually generated an NSLog explicitly asking for an implementation to be contributed. Maybe I should add a macro to NSDebug.h to do that? Having a completely unimplemented class there gives us a good placeholder for the documentation that tells people that the class is unimplemented, and maybe what the current plans are for it. I can see the argument here for removing the class (people aren't likely to think the class exists if there is no trace of it), but I think that a header file that's clearly a shell, and documentation that states that the class is unimplemented, is equally clear. We could document such empty classes with a note to say that someone (or nobody) is working on them, and a pointer to the task list on the website for current status. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
