Re: New features
Germán Arias schrieb: Hi Fred, If you are agree I will add the variables GSUseWindowFrameColorToMenu and GSMenuItemsBordered to GUI, but I don't know in what file are seated the defaults values of the variables. And I don't know if you are agree to add GSTaskBar (or whatever you want call it). To do this I need add some changes on NSApplication and NSWindow, and add another variable for use this, maybe GSUseGSTaskBar. Of course this need a tool that I call gstb. Greetings. Hi German, as for the changes to the menu drawing I would prefer to see the whole drawing here moved over into GSTheme and then it would be very simple to implement everything you want to do by a new specialised theme that just draws the menu differently. There isn't much point in inventing a special mechanism to handle one specific drawing aspect when there already is a perfect concept to deal with the whole thing. Specifically for the menu item colour I am thinking about making the system extension colour list, that is already used in GSToolbarView an official GNUstep mechanism, move the code over to NSColor and to add all the other colour definitions we have scattered in GNUstep gui (I think NSTableView uses some, hints to other places are welcome). That way a theme would just need to override one extra colour list. Is this a feasible approach for you? Or do you see a reason to do things differently? As for GSTaskBar I already replied on the discussion list. What I would like to know about the implementation is what change will be required in NSApplication and NSWindow. We should try to come up with a generic way to handle application icons here, so that we don't need to change our gui code the next time somebody comes up with an idea for a task bar tool. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: New features
El dom, 01-11-2009 a las 17:29 +0100, Fred Kiefer escribió: Germán Arias schrieb: Hi Fred, If you are agree I will add the variables GSUseWindowFrameColorToMenu and GSMenuItemsBordered to GUI, but I don't know in what file are seated the defaults values of the variables. And I don't know if you are agree to add GSTaskBar (or whatever you want call it). To do this I need add some changes on NSApplication and NSWindow, and add another variable for use this, maybe GSUseGSTaskBar. Of course this need a tool that I call gstb. Greetings. Hi German, as for the changes to the menu drawing I would prefer to see the whole drawing here moved over into GSTheme and then it would be very simple to implement everything you want to do by a new specialised theme that just draws the menu differently. There isn't much point in inventing a special mechanism to handle one specific drawing aspect when there already is a perfect concept to deal with the whole thing. To me this is good, the reason because I use a variable is because was the more easy way (At this moment I don't understand exactly how GSTheme work). Specifically for the menu item colour I am thinking about making the system extension colour list, that is already used in GSToolbarView an official GNUstep mechanism, move the code over to NSColor and to add all the other colour definitions we have scattered in GNUstep gui (I think NSTableView uses some, hints to other places are welcome). That way a theme would just need to override one extra colour list. Is this a feasible approach for you? Or do you see a reason to do things differently? in fact, that was my first intention on this. But when I saw that there wasn't a color for this, then I changed this on NSTitleView. But of course, a new color on this list is better. As for GSTaskBar I already replied on the discussion list. What I would like to know about the implementation is what change will be required in NSApplication and NSWindow. We should try to come up with a generic way to handle application icons here, so that we don't need to change our gui code the next time somebody comes up with an idea for a task bar tool. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: New features
Hi, Specifically for the menu item colour I am thinking about making the system extension colour list, that is already used in GSToolbarView an official GNUstep mechanism, move the code over to NSColor and to add all the other colour definitions we have scattered in GNUstep gui (I think NSTableView uses some, hints to other places are welcome). That way a theme would just need to override one extra colour list. Is this a feasible approach for you? Or do you see a reason to do things differently? Having a separate color for the menu bar and for the menus themselves would help also in making a better Windows theme, since WinXP and Vista have separate colors for that. Thank you. As for GSTaskBar I already replied on the discussion list. What I would like to know about the implementation is what change will be required in NSApplication and NSWindow. We should try to come up with a generic way to handle application icons here, so that we don't need to change our gui code the next time somebody comes up with an idea for a task bar tool. I miss to understand what's really about too. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
NSColor extensions (Was: New features)
Fred Kiefer schrieb: Specifically for the menu item colour I am thinking about making the system extension colour list, that is already used in GSToolbarView an official GNUstep mechanism, move the code over to NSColor and to add all the other colour definitions we have scattered in GNUstep gui (I think NSTableView uses some, hints to other places are welcome). That way a theme would just need to override one extra colour list. I am having second thoughts on my own proposal. The interplay between NSColor and GSTheme is already complex enough having to deal with just one colour list. Adding a second one will make it even harder to understand that code. My new idea now is to add the few additional colours we need to the System colour list, the one themes already override. Is this fine for everybody? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSColor extensions (Was: New features)
Hi, I am having second thoughts on my own proposal. The interplay between NSColor and GSTheme is already complex enough having to deal with just one colour list. Adding a second one will make it even harder to understand that code. My new idea now is to add the few additional colours we need to the System colour list, the one themes already override. Is this fine for everybody? That looks fine for me and that is what I originally thought. ANy arguments against that? (Richard?) Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSColor extensions (Was: New features)
On 1 Nov 2009, at 22:15, Fred Kiefer wrote: Fred Kiefer schrieb: Specifically for the menu item colour I am thinking about making the system extension colour list, that is already used in GSToolbarView an official GNUstep mechanism, move the code over to NSColor and to add all the other colour definitions we have scattered in GNUstep gui (I think NSTableView uses some, hints to other places are welcome). That way a theme would just need to override one extra colour list. I am having second thoughts on my own proposal. The interplay between NSColor and GSTheme is already complex enough having to deal with just one colour list. Adding a second one will make it even harder to understand that code. My new idea now is to add the few additional colours we need to the System colour list, the one themes already override. Is this fine for everybody? GSTheme already supports extra colors. The API is -colorNamed:state:cache: This is used for scroller slots (see GSThemeDrawing.m) and for thew color of a scrollview (NSScrollView.m) I don't see any point in changing the system colors ... they can remain as they are for OSX compatibility, but for theming our own controls we can keep things simple by using the GSTheme API directly. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
New features
Hi Fred, If you are agree I will add the variables GSUseWindowFrameColorToMenu and GSMenuItemsBordered to GUI, but I don't know in what file are seated the defaults values of the variables. And I don't know if you are agree to add GSTaskBar (or whatever you want call it). To do this I need add some changes on NSApplication and NSWindow, and add another variable for use this, maybe GSUseGSTaskBar. Of course this need a tool that I call gstb. Greetings. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Objective-C 2.0 and other new features in Leopard
Hi Gregory, Le 27 oct. 07 à 01:58, Gregory John Casamento a écrit : All, As many of you are probably aware, Apple released Leopard today. Leopard contains a number of enhancements which are important to us, one of which is Objective-C 2.0. Objective-C 2.0 = Odds are the existing developers will still write for versions of Mac OS 10.4 and below in order to have the widest possible range of customers, but eventually Objective-C 2.0 *will* become the standard. As more and more people upgrade this will become the case sooner rather than later. The core libraries of GNUstep should remain ObjC 1.0 compatible for the forseeable future, Sure. but I believe we need to start talking to the people in the GCC project to determine how we can help with the implementation of a gnu runtime that works with the new version of the language. I think it depends on the code Apple will submit back to GCC. Apple seems to be slowly moving away from GCC in favor of LLVM. From what I read, Xcode 3 uses LLVM to support ObjC refactoring. A new experimental C/ObjC front-end named clang was released as part of LLVM 2.1 (see http://clang.llvm.org/). Both clang and LLVM looks very promising. If adding ObjC 2 support to GNU runtime in FSF GCC context proves to be complicated, it could be simpler to add GNU runtime support to clang. It could also be helpful in future seeing that Apple will probably switch to LLVM for C, ObjC and C++ in next Mac OS X release. Interface Builder enhancements = The other feature which is interesting in it is the ability of InterfaceBuilder to support multiple languages including Ruby. The recursive descent parser I wrote for Gorm currently only handles Objective-C headers. Additionally, Gorm's internal data structures are decoupled from the type of archive that is being saved or read, nib, or gorm. When I added the nib support I rewrote nib/gorm support in both gui and in Gorm to support an architecture that allows classes which read/write different types of gui files to register themselves so that they would be considered when a gui model is loaded. Yesterday night, I spent some time dipping into new developer documentation and API. Interface Builder seems to have been massively rewritten. In addition to what you already mentioned, the interesting stuff seems to be: - new UI - new nib format (version 3) and new xib format (text-based format to better integrate with SCM) - new IB palette API replacing the previous one http:// developer.apple.com/leopard/devcenter/docs/documentation/ DeveloperTools/Reference/InterfaceBuilder_framework/index.html http://developer.apple.com/leopard/devcenter/docs/documentation/ DeveloperTools/Conceptual/IBPlugInGuide/index.html I am planning on moving Gorm to a more bundle/plugin oriented architecture in the future. This has a number of implications: Gorm will be able to: 1) parse multiple languages Would be nice. 2) generate multiple languages (for class files) 3) read/write any type of gui model for which it has a plugin available * gorm * nib * gmodel... etc I'm specially interested by such public API. I have begun to work on a new GUI model that can describe composite documents and UI in the same format. I would like to be able to load and save this model directly (in Gorm and in applications) rather than generating it from GNUstep view hierachy on nib loading. Cheers, Quentin. -- Quentin Mathé [EMAIL PROTECTED] ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Objective-C 2.0 and other new features in Leopard
Fred, The previous email wasn't meant to address anything outside of how ObjC 2.0 directly impacts GNUstep. Nor was it meant to cast an optimistic or, indeed, pessimistic slant on things. Neither is this one, for that matter. That being said, you and I have discussed the these very issues last time we spoke. We need to figure out how to solve them. The development applications and libraries in GNUstep are complete for the most part. All of the important classes are there and, with Gorm and Project Center, all of the important functionality is there. I think that part of what we're seeing is due to that. The perception is that there is not much left to do on the core libraries themselves. Here are the challenges that I see (in order of priority): 1) Applications... We need a comprehensive suite of applications for GNUstep. Something that, when someone uses them they have an integrated experience. We currently don't have that. 2) GUI... Apologies to anyone who's in love with the old interface and you know who you are, it's extremely dated. Etoile is helping with that, but many people, when they try GNUstep.. they try the core project and they see the old NeXTSTEP-ish GUI. This GUI is not as attractive as some of the current GUIs out there. We need to make it so. A pretty gui can be very compelling to both users AND developers. 3) Repository... I think we need to simplify a number of things with respect the repository. It is currently hard for people to check GNUstep out because of the structure it was given in SVN. You can't simply follow the instructions on the GNA website to make it work but you need to checking from devmodules. We should be able to put something into the repository which will let people check out in a more normal fashion. 4) Thinking differently... In my experience GNUstep is often perceived as doing things differently or weirdly because we don't follow the current standards. Usually, these standards are set by people who are using C++ or C based libraries which are no where near as dynamic as what GNUstep has to offer. Honestly, call me an idealist, byt I think that the way we do things is often better both in execution and design. From how our make system works to Gorm to how the backend works. GNUstep is a better system than GNOME or KDE in it's design. However.. all of that being said... when we do things differently, it might be useful for us to determine if there is a way to bridge the gap. We've already taken steps towards addressing #4 earlier this way with Nicola's changes with gnustep-make-2.0 (for which kudos are long overdue... he did an excellent job.. thank you Nicola) since they allow for installing GNUstep in different layouts... including one that is FHS compliant, but we need more. Also... we should emphasize *publically* what we've done more than we do. In the past two years we have been ahead of Apple twice or more in a number of things: 1) 64 bit support on Intel. GNUstep had this way before Apple did! 2) AppKit on openmoko -- while the iPhone debuts with a pitiful API... we have a full AppKit available! 3) Support for multiple model formats! last I checked Apple only supports .nib files for Cocoa/Carbon (and the second is being dropped). These are not optimism but statements of fact. It's too late to say anything about the first one, but it's certainly not too late to talk about 2 and 3. We have a lot of challenges ahead of us. Please tell me your thoughts on these points. Later, GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Fred Kiefer [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: GNUstep Developers gnustep-dev@gnu.org Sent: Monday, October 29, 2007 8:09:32 PM Subject: Re: Objective-C 2.0 and other new features in Leopard This is a very optimistic view of things, which I cannot share for the whole of GNUstep at the moment. My feeling is the race is over and we lost. Apple has just released a shining new version of there system and GNUstep is rather stagnant. We are no longer attracting old or new developers and it doesn't look like this is going to change. Have a look at the Changelog files from the last half year and you will understand what I mean. Not even the paid coders from GSoC made any difference. We urgently need to change the way GNUstep appears to the outside world, or we will become as obsolete as now seem. Personally I am thinking about reducing my involvement with GNUstep. It still is fun to hack way on GNUstep, but trying to get the library out of its current stagnation phase would require a bigger effort, which I cannot see at the moment. Cheers, Fred Gregory John Casamento wrote: All, As many of you are probably aware, Apple released Leopard today. Leopard contains a number of enhancements which are important to us, one of which is Objective-C 2.0
Objective-C 2.0 and other new features in Leopard
All, As many of you are probably aware, Apple released Leopard today. Leopard contains a number of enhancements which are important to us, one of which is Objective-C 2.0. Objective-C 2.0 = Odds are the existing developers will still write for versions of Mac OS 10.4 and below in order to have the widest possible range of customers, but eventually Objective-C 2.0 *will* become the standard. As more and more people upgrade this will become the case sooner rather than later. The core libraries of GNUstep should remain ObjC 1.0 compatible for the forseeable future, but I believe we need to start talking to the people in the GCC project to determine how we can help with the implementation of a gnu runtime that works with the new version of the language. Interface Builder enhancements = The other feature which is interesting in it is the ability of InterfaceBuilder to support multiple languages including Ruby. The recursive descent parser I wrote for Gorm currently only handles Objective-C headers. Additionally, Gorm's internal data structures are decoupled from the type of archive that is being saved or read, nib, or gorm. When I added the nib support I rewrote nib/gorm support in both gui and in Gorm to support an architecture that allows classes which read/write different types of gui files to register themselves so that they would be considered when a gui model is loaded. I am planning on moving Gorm to a more bundle/plugin oriented architecture in the future. This has a number of implications: Gorm will be able to: 1) parse multiple languages 2) generate multiple languages (for class files) 3) read/write any type of gui model for which it has a plugin available * gorm * nib * gmodel... etc Regards, -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
