Re: [Gnustep-cvs] r23971 - in /libs/back/trunk: ChangeLog Source/x11/XGServerWindow.m Source/x11/XIMInputServer.m
David Ayers wrote: > Fred Kiefer schrieb: >> Author: fredkiefer >> Date: Fri Oct 27 14:25:26 2006 >> New Revision: 23971 >> >> URL: http://svn.gna.org/viewcvs/gnustep?rev=23971&view=rev >> Log: >> Small correction to adopt to base change also remove annoying warning. >> >> Modified: >> libs/back/trunk/ChangeLog >> libs/back/trunk/Source/x11/XGServerWindow.m >> libs/back/trunk/Source/x11/XIMInputServer.m > > I still feel that GetEncodingName (or GSEncodingName, or > GSNameFromEncoding()) is generally useful. Does anyone else agree? I think it may be. I think, though, its a specific case of a more general issue we have which is Additions in policy and practice. We've got a systemic issue to resolve. Trying to argue individual functions is just side-stepping in my view. Time for a thread on this I think... Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Backend <-> GUI Library Interaction
Hi Christopher, Nice to hear from you... Christopher Armstrong wrote: There are outstanding issues with the windows backend related to window management. I believe some of these can be fixed by responding to certain Win32 window messages that MSWindows posts out. I am referring to the problems with window layering/levels/ordering and related focus issues that seem to affect everything from windows going missing to modal windows playing up. Not to mention the click twice to edit problem ;) There are some methods which appear in GSDisplayServer that appear to relate to these things. Without checking in detail what gnustep-gui does, could I get some clarifications on how the following methods work in response to certain inputs/outputs. - (void) orderwindow: (int) op : (int) otherWin : (int) winNum This one does appears to do window ordering (to state the bleedingly obvious). Obviously when a window is ordered it should obey the window level that is set. It should order self relative to otherWin according to op (NSWindowAbove, NSWindowBelow etc), staying within it's level. Take a hypothetical situation with three windows: A - window level 0 B - window level 50 C - window level 0 C is above A. B is on top of A & C (in terms of Z-order). So we have B-C-A (z-order front to back) if orderwindow was called to place A on top of B, should it order A to the top of its window level (i.e. between C and B) or should it ignore the message? I'm not sure what Cocoa does and it would be best to behave compatibly. That said, I think it should reposition itself to the top of its level so we'd get B-A-C Say the reverse happened (orderwindow was called asking it to order a a lower level window above a higher level window), what should occur in that case? The backend currently does what gnustep-gui tells it to do, ignoring window layering. That is wrong. Layering should be respected at all times. In the AppKit, there are two notifications, NSApplicationDidBecomeActiveNotification and its counterpart NSApplicationWillBecomeActiveNotification. Are these supposed to be sent through an application when one of it's windows is made "active" (i.e. becomes key)? Or is it when an application begins responding to event messages? ?? we have NSApplicationDidBecomeKeyNotification and NSApplicationDidBecomeMainNotification Do don't have NSApplicationDidBecomeActiveNotification - (void) setinputfocus: (int) winNum In GNUstep parlance there appear to be two things: a key window (which responds to keyboard events) and a main window. Is this correct? How exactly does a main window fit into the window focus equation? Is setinputfocus: supposed to main a window "key"? If a window is not to become the key window (e.g. some floating palette windows), does gnustep-gui take messages from the backend that the window was made the key window, and respond by making another window the key window? setinputfocus: sets focus to the window so it will receive key events. This is the X11 idea of focus, by the way. So on windows it makes the window active. The main window has a responder chain to processes the menu etc. So if you have a floating palette it can become 'key' but will never be 'main'. Win32 provides some window messages such as WM_ACTIVATE (a window in an application was given/lost the keyboard focus), WM_ACTIVATEAPP (your application itself lost/gained the keyboard focus) and WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED (called for a litany of window resize/move/focus/Z-order events where the outcome can be "adjusted"). I think these could help. Probably, although correcting calls to SetWindowPos() should fix the vast majority of problems. Does anyone have some guidance on this matter? I would like to start investigating some fixes so that perhaps I could get this working on Windows properly. Great. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r24082 - in /tests/testsuite/trunk: ChangeLog base/NSCalendarDate/basic.m base/NSCalendarDate/test00.m base/NSCalendarDate/test01.m base/NSCalendarDate/test02.m base/NSDate/create.m
David Ayers wrote: Richard Frith-Macdonald schrieb: On 13 Nov 2006, at 21:09, David Ayers wrote: --- /tests/testsuite/trunk/base/NSDate/create.m2006/11/13 I'm not sure about this change to the test suite... Does this imply that constructing an NSDate with an ISO date without specifing the time is invalid? I'm afraid that may break some adaptor implementations where the database fields differentiate between dates and timestamps. Yes it does mean that it's invalid ... if you want to create a date from a string without the timestamp then the format should not contain a timestamp part. Such code would not work on MacOS-X (or with the base library with the appropriate bugfix). The method initWithString... is explicitly documented to say that the string must match the format. Well I guess that's a unfortunate result of an evolving API. It implies that the date class of an EOAttribute must be an NSCalendarDate (or subclass thereof) since NSDate does not have the API to specify a format. I'm almost certain (but just haven't found to verify) that OPENSTEP allowed ISO dates without timestamps for NSDate class. But oh well... Umm.. doesn't it simply need to comply with a format that an NSDateFormatter can parse? Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Window manager interaction
On 18/10/2009, at 02:45 , Richard Frith-Macdonald wrote: On 17 Oct 2009, at 12:04, Philippe Roussel wrote: On Sat, Oct 17, 2009 at 07:02:12AM +0100, Richard Frith-Macdonald wrote: It sounds reasonable to allow interface style to control that sort of thing, and the behavior you suggest makes sense for a windows app. Just for the record, I like the vertical menus :o) Anyway ... see what you think of the change to allow unhide by showing miniaturised windows (eg in a task bar). It works for me (under Metacity), thanks Richard ! I think this is a big step for better integration. I would prefer something to appear in the task bar instead (so demanding...) of the appicon but it's a start. One option might be to scrap the backend miniaturisation/ deminiaturisation API entirely, and have the frontend strictly implement that using the window/miniwindow counterpart pairing. So to miniaturise a window, we order in the counterpart miniwindow (implicitly ordering the main window out), and to deminiaturise the window, we order it in (implicitly ordering the miniwindow out), and let the backend decide what it's going to do about the way it displays that on-screen. In the case where we don't have real counterpart miniwindows because the window manager is actually just putting labels on a taskbar, i guess the backend could provide some sort of dummy placeholder. Anyway .. that's just an idea ... don't know how much it would really help simplify things. Actually, I think it would simplify things a great deal if we dropped the miniwindow entirely. I believe the fundamental problem here is one of design and the flaw is trying to get -gui to handle miniwindows. For any compatibility desktop we want to consider (GNOME, KDE, MS-WIN...) the answer is conceptually straight-forward: a window sets its state to whatever, including MAXIMIZED, ICONIFIED/ MINIMISED the desktop environment does the display So what -gui should be doing is just that, setting the window state appropriately and letting the backend translate that into the desktop environment. The architecture is supposed to go like this: The application handles it's windows and draw in them/etc. This is - gui & -back. The window manager decorates the windows and provides the mechanisms for users to interact with them. (Move them around, re-layer, pin, show/hide, whatever) The application manager (pager) handles launching applications, showing what is running and switching between them. This is the taskbar / kicker / fiend / dock thing. This is the thing which would be displaying miniwindows for those desktop environments where its appropriate. It seems to me that we're trying to get -gui/back to sometimes be a window manager and sometimes be an application manager and getting (understandably) very confused. Regards, Sheldon Checked for Virus & Spam by West Australian Networks Internet Service Providers see www.westnet.net.au ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/base ChangeLog Headers/Foundation/...
Richard Frith-Macdonald wrote:
> On 2005-03-15 08:26:46 + Stefan Urbanek <[EMAIL PROTECTED]>
wrote:
>
>> Hi,
>>
>> In GSFindNamedFile you use:
>>
>> file_name = [NSString stringWithFormat: @"[EMAIL PROTECTED]@", aName,
>> anExtension];
>>
>> should not that be rather:
>>
>> file_name = [aName stringByAppendingPathExtension:anExtension];
>
>
> Yes. Thanks.
> I'm still finding oddities in this patch ... and tidying up when I notice
> them.
Actually, no it shouldn't be. At least, not from my design view.
There was a reason I did (A) rather than (B):
GSFindNamedFile is supposed to be called like this:
located_app = GSFindNamedFile( NSStandardApplicationsPaths(),
"MySpecialApp",
"app");
or
icon_for_file = GSFindNamedFile( icon_places,
"TextFile",
"png");
For this sort of use stringByAppendingPathExtension goes through various
steps and calls before hitting stringWithFormat as above so (A) is
faster and incurs less overhead.
The benefit of using (B) means
icon_for_file = GSFindNamedFile( icon_places,
"TextFile/",
"png");
will still find "TextFile.png" where as for (A) it would fail trying to
find ".png" in the "TextFile" sub-directory of each place in the search
paths.
From an API conceptual point of view aName should really be the name of
the file and not a path spec. The pathing is handled already by the
array of places. If you wanted to search in the "TextFile" sub-directory
you'd add it to each element of the path array, *not* the name.
Regards,
Sheldon
{who sometimes has method behind his madness}
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Installation on windows (fwd)
Richard Frith-Macdonald wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2005-03-14 19:43:01 + Alex Perez <[EMAIL PROTECTED]> wrote: Nicola Pero wrote: here are currently issues with the path handling which causes certain things to only work inside the msys environment. If you remove it before those issues are fixed, you will introduce more problems. Thanks -- ... there might be some confusion ? ;-) ... we are talking of the msys developer toolkit (ie, additional developer tools), not of msys (the base development environment). Anyway. Which issues ? Which path handling ? :-) Unicode path handling under win32 is basically completely broken. I am not privy to the details, but all I can say for sure is that I believe it manifests itself as a problem when you launch a gpbs or gdnc (which are both true GNUstep tools, unlike gdomap, which AFAIR is a C app) from a path with a space in it, it fails miserably. This should not happen. Windows is riddled with paths with spaces, and they must be properly supported. I understand the inherent limitations of GNU Make and GNUstep-make and spaces, but this is not what I am referring to. GNUstep apps at runtime should have 100% support for being launched in a directory with spaces, as well as opening files up in directories with spaces. The current installer "works around" this problem by installing GNUstep to c:\GNUstep, which is in violation of the Windows FSH, but it's the only solution that currently works without fixing the problem with win32 path handling properly and completely. To the best of my knowledge, the problem with launching apps in paths containing a space was fixed about a month ago, and was due to a bug/feature of the way that windows deals with the arguments when spawning a subprocess ... it had nothing to do with unicode string handling. Certainly, I can run gdnc from directories whose names contain spaces. Also, I have never heard of gnustep having any problem opening files whose names contain spaces. Which is not to say that there can't be problems where application programmers parse strings assuming that spaces are being used as filename separators. Anyway, there are no outstanding unfixed bug reports on the issue of spaces in the base library, and no windows specific bug reports for unicode problems that I can remember at all. Let's fix them if we have any. Sheldon Gill knows probably better than anyone else what needs to be done to resolve this. I suggest you send him an e-mail, since I don't think he's subscribed to this list currently. I've been discussing various aspects of win32 gnustep issues with him privately recently, and he knows far more about it than I'd ever care to know :) You can contact him at [EMAIL PROTECTED] , or if he is lurking on the list reading this, I'd like to encourage him to come out of his hole and speak to this :) *Emerges from hole* Hmm... FYI my involvement has been interrupted by RL and my Wallstreet not booting. Also other unspeakable things on the doze box. By the way, the spaces in paths isn't really the issue we were discussing. It's definitely worth checking with Sheldon in case he knows of any bugs he hasn't bothered to report ... though my impression was that most of his problems were wishes that things would work more 'naturally' in a windows environment rather than bugs as such, and I think most/all of the ideas discussed with him have been applied by Adam recently. Ahhem! ...bothered... ?!! I've a range of "problems" regarding GNUstep in respect to the file system, some of which are wishes for better behaviour but some are certainly what I'd categorize as bugs. These "wishes" aren't restricted to the windows environment either. Some of the ideas discussed have begun to be implemented in stages. I wouldn't call it most and definitely not all. At the path handling on windows, essentially the issues arise because OpenStep -> POSIX -> (emulation) -> Win32 is the current layering and that introduces all sorts of issues as we move from layer to layer. The "impedance mismatch" gets compounded and we add both overhead and complexity in the process. Unicode compounds the issues. Especially as there are Unicode issues with mingw and msys. I'm not sure what exactly has been fixed for the latest release but definitely are there for earlier ones. Internally, the current -core code has some parts working with unicode strings for the file system while other parts don't. After quite some investigation I believe the best way is to go OpenStep -> Win32 as far as possible. This means that all things should be in UTF-16 and left untransformed as far as possible and reasonable. The only transformation which should be done is variable expansion on paths read from the environment/registry so that absolute paths are used
Re: Installation on windows (fwd)
Richard Frith-Macdonald wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2005-03-16 06:06:11 + Sheldon Gill <[EMAIL PROTECTED]> wrote: I've a range of "problems" regarding GNUstep in respect to the file system, some of which are wishes for better behaviour but some are certainly what I'd categorize as bugs. These "wishes" aren't restricted to the windows environment either. Perhaps starting with reporting individual bugs would make sense ... since they generally only get fixed if people know about them, and a problem broken down into individual parts is much easier to deal with. Sure. I've not done much testing with the latest revisions. If I have a test case to provide demonstrating a bug, I'll do so. In the interim, a review of the code has suggested a number of possible bug scenarios. I will get to them... Some of the ideas discussed have begun to be implemented in stages. I wouldn't call it most and definitely not all. At the path handling on windows, essentially the issues arise because OpenStep -> POSIX -> (emulation) -> Win32 is the current layering and that introduces all sorts of issues as we move from layer to layer. The "impedance mismatch" gets compounded and we add both overhead and complexity in the process. Unicode compounds the issues. Especially as there are Unicode issues with mingw and msys. I'm not sure what exactly has been fixed for the latest release but definitely are there for earlier ones. Internally, the current -core code has some parts working with unicode strings for the file system while other parts don't. I see support for unicode filesystem as a strong wishlist item... it's not part of OpenStep, but I feel we should add it since my guess is that the windows implementation of the the posix functions used in a lot of places does not handle it. I disagree that Unicode to the file system isn't part of OpenStep. Mostly, the OSAPI uses NSStrings passed to NSFileManager or NSFileHandle. It is Unicode clean as far as possible. There is even a specific method to transform from an NSString to a path string which the OS system routines can handle to provide compatibility between the OpenStep fully unicode API and the underlying OS requirements. There are string methods to help manipulating strings which represent paths and many of them are rather POSIX focused but that is a different thing. Mostly they don't care path separator etc and are done in a sufficiently abstract way so it doesn't matter. After quite some investigation I believe the best way is to go OpenStep -> Win32 as far as possible. This means that all things should be in UTF-16 and left untransformed as far as possible and reasonable. I'm not sure what you mean above ... If you simply mean that we should use win32 api calls directly (eg CreateFile() rather than creat()), then I think that's uncontroversial and is the direction we are moving in for the sake of performance and aesthetics. Then we are in complete agreement about this. Excellent! One thing that bugs me about current code is that, because it was written by a variety of unix people, it uses fopen(), fread() fclose() etc in a lot of places where it should realy be using NSFileHandle/NSFileManager to encapsulate system dependencies. Thats' not to say that the existing code is buggy in any way, just that it's less easily maintainable/portable than it might be. Again, we are in complete agreement. In fact, I'd already done work in this regard but there wasn't any point in submitting it as it followed on from previous work on NSPathUtilities, NSFileManager and the Win32 support routines. The only transformation which should be done is variable expansion on paths read from the environment/registry so that absolute paths are used internally in their native form. This is the safe, sane and future compatible way to go. Least harm, smallest set of assumptions. Leads to least code and smallest overhead. This does lead to some issues with the path handling NSString methods which need to be considered but they aren't show stoppers. There really just needs to be some consideration and handling of the non-POSIX Win32 case where: "\" is the separator "/" isn't the FS root symlinks don't exist "~" is meaningless I think on this point you are asking to break GNUsteps OpenStep/MacOSX compatibility and ignore the userbase of programmers wishing to write portable code. Umm.. no. I really don't want to break compatibility. In fact, I want to enhance it and make it easier. That doesn't mean, though, that I advocate doing everything to try and support existing code as written where it makes sense to have a better approach. I'd actually say that the current changes do more to break compatibility in porting code than my goal to do th
Re: Installation on windows (fwd)
Richard Frith-Macdonald wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2005-03-16 08:13:42 + Sheldon Gill <[EMAIL PROTECTED]> wrote: I disagree that Unicode to the file system isn't part of OpenStep. Mostly, the OSAPI uses NSStrings passed to NSFileManager or NSFileHandle. It is Unicode clean as far as possible. Hmm ... While I guess I can see why you might think that, I don't really see that as anything to do with the filesystem. OpenStep uses NSString objects internally, so inevitably the API to those classes passes NSString objects ... to me that implies nothing about the underlying filesystem support. Plainly having a unicode filesystem is a good thing, and I feel that support for unicode filesystems is a natural extension, but the support of unicode strings doesn't mean that unicode filesystems were supported. There is even a specific method to transform from an NSString to a path string which the OS system routines can handle to provide compatibility between the OpenStep fully unicode API and the underlying OS requirements. Specifically, that converts FROM and NSString (which may be thought of as unicode. even if it is oftern stored as 8byte characters) TO an 8-bit per character filesystem representation. This says that the internal format may be 16bit unicode, but the external one isn't ... OpenStep anticipates that the filesystem will be using CStrings rather than unicode. My take on that goes a little differently. It recognises that file system calls on the underlying OS probably require a CString. Exactly what type of CString can differ. On some platforms you'll need to convert to a specific codepage. On others it'd be preferred UTF-8. Having one call to convert makes it easy. I don't think it is mean as a convert to/from "internal" format mechanism. Its a convenient support mechanism when the underlying OS uses CString parameters. In the case of Windows, it can handle UTF-16 directly. In this case there are no code page or other encoding transforms that need to take place so you can always pass a UTF-16 string. There are string methods to help manipulating strings which represent paths and many of them are rather POSIX focused but that is a different thing. Mostly they don't care path separator etc and are done in a sufficiently abstract way so it doesn't matter. Yes ... I think we should try to keep things as abstract as possible and OpenStep goes a long way towards this. Agreed. Nice and abstract so mostly applications don't need to care too much. Umm.. no. I really don't want to break compatibility. In fact, I want to enhance it and make it easier. That doesn't mean, though, that I advocate doing everything to try and support existing code as written where it makes sense to have a better approach. I'd actually say that the current changes do more to break compatibility in porting code than my goal to do things cleanly "under the hood". The current situation forces localToOpenStep and openStepToLocal. These are extensions to the API and complicate things. In my view, they are unnecessary. We can do better without them. I'm not really happy with them ... but I'm not sure there is a better approach, and they seem to make things simpler than any alternative. A more efficient api might take 16bit character strings directly ... but then what about 32bit unicode strings etc etc. This API may require two stages (one to convert between external data format and NSString, and one to convert between external path format and internal path format), but it keeps additional methods to a minimum given that the This is the real point between us. I am sure there is a better approach and that is to do without them. Under MacOS-X, *nix and even YellowBox I could: * get an NSString from an environment variable via NSProcessInfo * Use that string as a path to NSFileManager I believe that's also the case in GNUstep (unless recently broken). The interesting question is to what extent path manipulation can be performed on such a string rather than whether it can be used literally. In GNUstep that's minimal. However, while it way work, I've not seen it recommended anywhere.. under gnustep-CVS I have to add an intermediate step: * get an NSString from an environment variable via NSProcessInfo * openStepToLocal the string You mean openStepPathFromLocal: ? Yes, I do. I often shorthand method/function names when I think its reasonably unambiguous. Must be the Aussie influence ;) The issue I have is this: You need to call the local/OpenStep conversion routines on Win32. You don't on other platforms. So it is actually making porting *more* difficult. These routines add semantic complexity. You have to keep track of when a string is in "internal" format and when it is in "external" format. * Use that string as a path to NSFile
Re: Installation on windows (fwd)
On reflection, it sounds like we agree about everything apart from whether to store system-specific or standardised paths internally (we may disagree about what the API implies in this regard too ... but I think the principle is the main issue). Pretty much. The principle, though, has implications on the whole engineering... We both seem to believe in much the same objectives, but disagree about how to achieve them. Yes. I'll try to clarify my reasoning in principle ... I think we want to be able to write portable code with minimal knowledge of filesystem differences, and to me it makes sense to say to application developers - Work to a single set of behaviors and use standard, simple mechanism for converting paths to/from the standard on the infrequent occasions when it is necessary to read in or write out local paths. To you it makes sense to say - determine what system your app is running on, and expect to use paths in the local format. Stick to the standard methods for path manipulation and there will be few occasions where you need to adjust your code to do things in a system specific way. A reasonable characterisation of our positions. My background is very much one of distributed programming, where an application will deal with input from many machines simultaneously. From that perspective, having different path representations on different machines is horrible. However, I do realise that it is an unusual perspective, and the vast majority of programs don't have an isuse with this. Actually, coming from SCADA & Process Automation, heterogenous multi-nodal systems aren't alien to me at all. I'm not sure of your requirement, here. I'm wondering why different machines are senting path representations for their local file system. If the situation is that they're sharing storage I can see why you'd send a path but then that is a path into the shared space. I'd have thought it'd be easy enough to send references relative to the mount point in which case your Win32 code would ensure it sends the path in an acceptible way for the transfer. The winbox won't share a mount point and will probably use UNC in this case so you are encountering the semantic differences. While my feeling is that the two approaches are fairly evenly balanced (leaving aside distributed systems, and the fact that we have one system already working in the libraries, and consideration for the existing application codebase), I'd like to hear what other people think about the general prionciples. So would I. Hence I've been quiet for a bit. Speak up, people. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rendering of fixed-width fonts
Adrian Robert wrote: On Mar 16, 2005, at 5:12 AM, Banlu Kemiyatorn wrote: On Tue, 15 Mar 2005 23:57:45 -0500, Adrian Robert <[EMAIL PROTECTED]> wrote: For another, I'm not sure when the y advancement should be used. I guess even the Japanese are mostly writing horizontally now, at least on computers? ;-) How very gaijin of you. How very gwailo of you. I have seen a *lot* of japanese text in the field of publishing that use vertical layout. Well, my confusion was this: since, at least in Chinese and Japanese, the same font can be used for either horizontal or vertical layout (correct me if I'm wrong here), and presumably has both x and y advancements set nonzero, how should a PS command like moveshow(txt) know to advance the point vertically or horizontally per character? The current implementation in Art just assumes horizontal. It seems like some type of layout preference info would need to be passed from a higher level. Welcome to the wonderful world of complex script layout. Truth is, it needs to be much more complicated than just "preference info". If Chinese & Japanese are confusing you, just wait til you hit Farsi! Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: More Windows stuff ... Gorm works ... sort of
... but I still think that assuming advanced building features in "core" components is not a good idea. Gorm is a "core" component and it would be nice if it was very portable and worked almost automatically as soon as the very basic stuff is ported to a platform. Support for weak symbols are hardly advanced, they have been a feature of ELF since it's creation. As I pointed out before, it's Window's use of the rather ancient COFF standard which is the real problem. I wanted to point out that weak-linking has been supported by Visual Studio (MS tools) since at least version 6 which is quite old now. The problem wasn't just the PE binary format, it also had to do with the run-time support in windows. The solution actually lies in the linker and a bit of library code, not the source nor the build system itself. It ends up working rather like CFM... Actually, Windows uses PE-COFF, which is still fraught with plenty of COFFish limitations, but it's extended enough that weak link support itself is actually supported by the spec. This is the support for which Aaron LaWhatsHisName has recently implemented in GCC and binutils. I didn't realise this had been done yet. I must investigate further. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [RFC: Rewriting of the GNUstep User FAQ, specifically re: Frameworks]
Alex Perez wrote: Folks, Since people (see http://osnews.com/comment.php?news_id=10182&limit=no )are actually reading the GNUstep User FAQ (see http://www.gnustep.org/resources/documentation/User/GNUstep/userfaq_1.html ), and the information in it regarding Frameworks is IMHO grossly out of date, I'd like to propose that it be revised to reflect the current state of Frameworks and also the fact that our pseudo-frameworks now work under windows, as well as describe what is required for "true" framework support (eg, linker and compiler support, binary format enhancement to ELF, etc) and perhaps even mention that Matt Rice has done some work towards this goal and to contact him if anyone is interested in it. What do you think? I think it is a good idea but that work on it should be held off for a little while. GNUstep is about to enter an 'unstable' cycle while important changes are made. This is the time when binary-incompatibilities are being introduced. Thus, I believe any current update on the faq will need updating again in the near future. If someone feels like doing it both times thats fine. Otherwise, perhaps a note to the effect: This FAQ is out of date. New FAQ will be issued in ?July? or something like that. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
More building on Win32
Hi, Building CVS GNUstep on W2k. No XML, no OpenSSL. There are, of course, warnings: Info: resolving ___objc_class_name_Object by linking to __impobjc_class_name_Object (auto-import) but checking the import table is interesting. The C runtime library gets imported twice and the objc library a great deal more than once. The end of the imports section lists it many times for a single entry point each time! Hence, instead of 6 imported libraries there are 45! What is giving rise to this behaviour and how do we fix it? Regards, Sheldon --- Import table (libraries: 45) --- objc.dll (imports: 64) __objc_class_name_Object __objc_class_name_Protocol __objc_exec_class __objc_msg_forward msvcrt.dll (imports: 7) _close _open _read _strdup _tzname _tzset _write msvcrt.dll (imports: 76) __dllonexit __mb_cur_max __p___argc __p___argv __p__environ _chsize objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Protocol objc.dll (imports: 1) __objc_class_name_Object objc.dll (imports: 1) __objc_class_name_Object objc.dll (imports: 1) __objc_class_name_Object ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crosscompiling gnustep
Adam Fedor wrote: On Apr 26, 2005, at 12:19 PM, Stefan Urbanek wrote: Besides that, I expect GNUstep make to want me to run GNUstep.sh later during compilation. However, what GNUstep.sh I should run? The one I have just installed? But if that script calls some binary executables, they will not work on my system. Er, well you should run the GNUstep.sh you just installed to set up the build environment right. But you are right - there are some binary executables that will run Only one: user_home. Host native version will work fine. Just make sure you don't have a ~/GNUstep.sh to confuse things. One way to ensure things are clean is to do your cross-compiling as a specific user with the environment set up for it. user_home should just not run when we are cross compiling. The more problematic one is which_lib, which should really be compiled to run locally I guess... I think we used to have which_lib written as a perl script to deal with this problem before, but that was removed long ago, probably because no one every really used cross compiling... user_home and which_lib should work fine by using the host native versions. Just move the target versions away and copy in the host ones. Neither do very target or host specific things at the moment. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Crosscompiling gnustep
Stefan Urbanek wrote: On Tue, 2005-04-26 at 14:40 -0600, Adam Fedor wrote: On Apr 26, 2005, at 2:28 PM, Stefan Urbanek wrote: On Tue, 2005-04-26 at 14:24 -0600, Adam Fedor wrote: On Apr 26, 2005, at 1:11 PM, Stefan Urbanek wrote: ... checking callback.h usability... yes checking callback.h presence... yes checking for callback.h... yes checking "for forwarding callback in runtime"... yes checking "FFI library usage"... none Well, the config.log file would help here. It's just trying to see if the ffcall libraries link correctly, which should work when cross-compiling. http://stefan.agentfarms.net/Download/GNUstep/Trash/config.log Well here's the error message. Did ffcall really get installed correctly? /home/stevko/Developer/Windows/lib//libcallback.a: could not read symbols: Archive has no index; run ranlib to add one I run ranlib manually. From ffcall installation output I see: ... /usr/bin/install -c -m 644 .libs/libcallback.a /home/stevko/Developer/Windows//lib/libcallback.a ranlib /home/stevko/Developer/Windows//lib/libcallback.a chmod 644 /home/stevko/Developer/Windows//lib/libcallback.a ... the ranlib line should read: i586-mingw32-ranlib /home/stevko/Developer/Windows//lib/libcallback.a Looks like misconfiguration of ffcall or a bug there. Then I used this configure command with --includedir and --libdir added: [EMAIL PROTECTED] base]$ ./configure --host=i586-mingw32 --prefix=/home/stevko/Developer/Windows/GNUstep --enable-ffcall --with-ffi-include=/home/stevko/Developer/Windows/include/ --with-ffi-library=/home/stevko/Developer/Windows/lib/ --includedir=/home/stevko/Developer/mingw/include/ --libdir=/home/stevko/Developer/mingw/lib I ended with: Compiling file NSPathUtilities.m ... NSPathUtilities.m: In function `NSHomeDirectoryForUser': NSPathUtilities.m:789: warning: implicit declaration of function `getpwnam' NSPathUtilities.m:789: warning: assignment makes pointer from integer without a cast NSPathUtilities.m:790: error: dereferencing pointer to incomplete type NSPathUtilities.m:792: error: dereferencing pointer to incomplete type make[2]: *** [shared_obj/NSPathUtilities.o] Error 1 make[1]: *** [libgnustep-base.all.library.variables] Error 2 make[1]: Leaving directory `/home/stevko/Developer/Sources/gnustep/core/base/Source' make: *** [internal-all] Error 2 It is too late now, i have to go to sleep. If anyone has any hints what should be done and what should do as next steps, let me know. I am also interested in the GNUstep.sh problem mentioned before. For GNUstep.sh see other post. Problem here is __MINGW__ doesn't seem to be defined. It should be in Headers/Additions/GNUstepBase/preface.h If you're cross-compiling for windows getting that definition happening is pretty vital! Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
Philippe C.D. Robert wrote: On May 6, 2005, at 10:10 PM, Markus Hitter wrote: P.S.: All the methods handling C strings are in the depreceated section now. That is not quite true, actually many of them are replaced by methods taking an encoding parameter in addition. E.g. cString becomes cStringUsingEncoding: and so on. That is right. As I see it, they are rightly trying to move things forward for better internationalisation. If you use a C string it needs to have a specific encoding. Relying on a "default" encoding and using a C string isn't a good idea. In the modern unix world you are much better off using UTF8 strings. In the modern windows world it should all be UTF16 I'm working on string methods now as part of my path & win32 effort, if anyone is interested. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
Helge Hess wrote: How disappointing! :-| Yes, it is rather. I suppose it was dropped because people did not understand what it is doing / good for and misused the methods (pretty similiar to - fileSystemRepresentationWithPath: which is seldom used). I'm sure that has a lot to do with it. There isn't anything in the on-line documentation so far which would point to reasons. It could also be a prelude for newer APIs which rely on UTF16. That is not quite true, actually many of them are replaced by methods taking an encoding parameter in addition. E.g. cString becomes cStringUsingEncoding: and so on. Thats not the same. The -initWithCString: per definition takes strings in the system encoding, so if you are getting a value from a standard C-API (say readlink()) you now need to do: s = [NSString stringWithCString:buf encoding:[NSString defaultCStringEncoding]]; which obviously is a major inconvenience (and slowdown!) when interfacing with C. Yes, except on MacOS-X you'd go s = [NSString stringWithUTF8String: buf]; which is an easy update from s = [NSString stringWithCString: buf]; so for it isn't a significant inconvenience. As for slowdown, I'm not sure that Cocoa doesn't now call down to specify the encoding anyway. I'd also say that a Cocoa application should never call readlink() anyway. It's supposed to resolveSymLinksInPath ;) That is right. As I see it, they are rightly trying to move things forward for better internationalisation. I wonder how this is supposed to improve internationalization. A pretty good optimization which had _no_ drawback wrt internationalization was dropped in favor to a method which will hardly get used in practice. See above. I think you're right and encoding: will not be used very much. I'm sure this is what Apple wants. Instead they could have used their energy to add Cocoa API for supporting arbitary encodings without resorting to CoreFoundation. _That_ would have been an improvement for internationalization. Absolutely. It seems a very simple thing to do as well. Actually, a lot of the revisions are IMO half-way. Where there is a reasonable CF way they often point and that instead. Worse-is-better Relying on a "default" encoding and using a C string isn't a good idea. Why not? This way its guaranteed to match. The "default" encoding is the encoding configured in your Unix environment. You know, modern Unix _has_ proper support for localization (see LANG, LC_xxx etc)? I know. I can similarly argue that the "default" encoding is always UTF8 so just go with that. The real problem I see with relying on the "default" encoding is when moving from machine to machine. In the modern unix world you are much better off using UTF8 strings. In the modern windows world it should all be UTF16 Hm, yes? This is why UTF-8 or UTF-16 might be the default C-String encoding if this is the case. This is what -initWithCString: aka defaultCStringEncoding is made for! If your Unix does UTF-8, you just switch the default encoding and everything works instantly. You're forgetting. This is Cocoa and there is no your Unix and mine. There is only MacOS-X. Also your point doesn't apply since we already have - initWithUTF8String: (every C API which doesn't use the system encoding most likely uses UTF-8 on Unix) and -initWithCharacters:. So dropping -initWithCString: gains you nothing here. I do get your point. I think the rationale has more to do with social/human factors and technical merits. Oh well, Exactly. I'm trying to defend Apples decision so much as interpret it. I've come to the opinion that it isn't entirely without merit. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
I'm working on string methods now as part of my path & win32 effort, if
anyone is interested.
I'd be interested in knowing what exactly as I have a load of
uncommitted windows path changes on my system (I was waiting for
feedback on the last tranch of changes), and I'm also occasionally
updating bits and pieces to match MacOS-X API.
Hmm...
In no particular order and off the top of my head:
* NSHomeDirectoryForUser() now finds other users on Win32
* Additional directory keys for NSSearchPath() including
all the new Tiger keys.
* GSSearchPath() for porting/compatibility
* New implemenation of SearchPathForDirectories; O(1)
Very much faster and more readily extensible
* Paths from registry in Win32 for mingw32 native
* standardised, improved way to determine win32 IsExecutableFile
* hide/show extensions on win32 in sync with Explorer
* Flexibilty improvements in FS layout for platform-specific packaging
Better PLATFORM_SUPPORT. {stuff I was mentioning to Helge}
* Some string methods do better argument checking and/or raise an
exception when invalid/nil
* Documentation for all this and more
Still progressing
* Path handling fixes in the rest of base and gui: where we have
assumptions about layout which are no longer valid or where
the code can be cleaned up
* More and better use of Unicode and Win32 api. We should be
using either Step or native methods as far as possible to
improve behaviour. This will be ongoing for a while...
* Framework support on win32. With my _find_framework() in NSBundle we
can now properly locate the framework directory and so know exactly
where the DLL is. We can load it explicitly when needed.
Its a case now of linking and symbol resolution.
A ways off (because of time)
* Remove PathHandling mode
I'm quite concerned about PathHandling mode and want to remove it. I
don't think it's necessary and adds more confusion and complexity.
Currently, it's a global variable. The mode could be changed by a
loadable bundle without the application code being aware of it.
Hence, code can be expecting to run in one mode and be invoked when it's
different.
Further, it could be changed in one thread and mess up the processing in
a different thread which happens to be executing at that time.
Under this scheme, to write safe code you need to
1 check what the current mode is and remember it
2 set it to what you expect
3 process
4 set it back to what it was so you don't confuse other things
5 pray no other thread is changes mode under you
I understand the concerns which lead to implementing the mode but I
really think it isn't needed and adds more complexity than it solves.
* review and recommendations for NSString & NSFileManager
I've argued that we don't need Local<->OpenStep conversion generally
We also don't need the special ~drive and [EMAIL PROTECTED] notations. For
starters, though I find it bizarre I have come across accounts with user
name eg 'a'. Anyway, we don't need the ~ encodings.
I'm working on demonstration code to remove these by defining clear path
handling semantics which are appropriate for *nix and for win32 without
confusing either.
Current behaviour can be apparently inconsistent and confusing:
Path string for test is /./Development
Standardised '/./Development'
FileSystem rep'\.\Development'
OSFromLocal gives '/./Development'
Path string for test is F:/./Development
Standardised 'F:/./Development'
FileSystem rep'F:\.\Development'
OSFromLocal gives '~F//./Development'
Path string for test is F:\.\Development
Standardised 'F:/./Development'
FileSystem rep'F:\.\Development'
OSFromLocal gives '~F/Development'
Path string for test is F:\\.\Development
Standardised 'F://Development'
FileSystem rep'F:\\Development'
OSFromLocal gives '~F/Development'
Path string for test is F://./Development
Standardised 'F://Development'
FileSystem rep'F:\\Development'
OSFromLocal gives '~F///./Development'
* string optimisations for the Win32 API where buffers are used
extensively. Initial testing suggests significant savings are possible
but I want to investigate further.
I'm sorry if this was a little terse but I'm pressed for time right now.
Off to see clients...
Regards,
Sheldon
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Apple changed documentation for -[NSString stringByExpandingTildeInPath]
I'm working on string methods now as part of my path & win32 effort,
if anyone is interested.
I'd be interested in knowing what exactly as I have a load of
uncommitted windows path changes on my system (I was waiting for
feedback on the last tranch of changes), and I'm also occasionally
updating bits and pieces to match MacOS-X API.
Hmm...
In no particular order and off the top of my head:
* NSHomeDirectoryForUser() now finds other users on Win32
* Additional directory keys for NSSearchPath() including
all the new Tiger keys.
* GSSearchPath() for porting/compatibility
* New implemenation of SearchPathForDirectories; O(1)
Very much faster and more readily extensible
* Paths from registry in Win32 for mingw32 native
* standardised, improved way to determine win32 IsExecutableFile
* hide/show extensions on win32 in sync with Explorer
* Flexibilty improvements in FS layout for platform-specific packaging
Better PLATFORM_SUPPORT. {stuff I was mentioning to Helge}
* Some string methods do better argument checking and/or raise an
exception when invalid/nil
* Documentation for all this and more
Wow ... that's a lot of changes.
That's actually quite well contained, really. There is more of my
NSPathUtilities bit and a few more Win32 support routines. {Strings
excepted}
I found the new Tiger dirs to be amusing. I had to drop my
GSCacheDirectory and GSDesktopDirectory keys...
IsExecutable and show/hide extensions are pretty trivial NSFileManager
based on that.
I've also a rev for NSTimeZone which fixes some Win32 strangeness,
cleans a little code and provides for more flexible packaging but I
thought this was a little outside of this discussion. Again, it needs
the Win32 support improvements.
So I was thinking it'd be a reasonably straight-forward commit but there
is the binary compatibility break we're heading to, which is the right
time to do this.
* Remove PathHandling mode
I'm quite concerned about PathHandling mode and want to remove it. I
don't think it's necessary and adds more confusion and complexity.
As you know, we had much discussion about path handling, and there was
definitely no consensus ... so the current code is a compromise allowing
the various viewpoints to be more or less satisfied, and switching of
modes during runtime was purely for testing that. I think the aim is to
move to the 'do the right thing' mode once people are generally happy
(though perhaps mode control on process startup using an environment
variable will be supported).
In my view there should be one and only one mode. Well defined behaviour
that can be relied on.
The current behaviour of 'do the right thing' doesn't, in my view, do
the right thing and gives rise to some quite strange results on win32.
* review and recommendations for NSString & NSFileManager
I've argued that we don't need Local<->OpenStep conversion generally
We also don't need the special ~drive and [EMAIL PROTECTED] notations. For
starters, though I find it bizarre I have come across accounts with user
name eg 'a'. Anyway, we don't need the ~ encodings.
I'm working on demonstration code to remove these by defining clear path
handling semantics which are appropriate for *nix and for win32 without
confusing either.
I've already done that ...
That's why I wanted to know what you were doing :-)
I thought you might have. That's why I issued the invitation to ask ;)
Does this use the current path handling mode semantics?
* string optimisations for the Win32 API where buffers are used
extensively. Initial testing suggests significant savings are possible
but I want to investigate further.
Sounds good.
Yes and people will be happy that things are faster. I'm not sure
they'll like delving into the code, though. I'm taking GStr here.
Regards,
Sheldon
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/base/Resources GNUmakefile Languag...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Sheldon Gill <[EMAIL PROTECTED]>05/05/10 10:28:42 Modified files: core/base/Resources: GNUmakefile core/base/Resources/Languages: Locale.aliases Added files: core/base/Resources/Spanish.lproj: Localizable.strings Log message: * Resources/GNUmakefile * Resources/Languages/Locale.aliases * Resources/Spanish * Resources/Spanish.lproj/Localizable.strings Spanish localization from diemyr CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Resources/GNUmakefile.diff?tr1=1.14&tr2=1.15&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Resources/Languages/Locale.aliases.diff?tr1=1.4&tr2=1.5&r1=text&r2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Resources/Spanish.lproj/Localizable.strings?rev=1.1
[Gnustep-cvs] gnustep/core/base/Resources/Spanish.lproj
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Sheldon Gill <[EMAIL PROTECTED]>05/05/10 10:11:36 gnustep/core/base/Resources/Spanish.lproj Update of /cvsroot/gnustep/gnustep/core/base/Resources/Spanish.lproj In directory savannah:/tmp/cvs-serv6275/Spanish.lproj Log Message: Directory /cvsroot/gnustep/gnustep/core/base/Resources/Spanish.lproj added to the repository
[Gnustep-cvs] gnustep/core/base/Resources/Languages Spanish
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Sheldon Gill <[EMAIL PROTECTED]>05/05/10 10:39:51 Added files: core/base/Resources/Languages: Spanish Log message: * Resources/Languages/Spanish Spanish localization from diemyr CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Resources/Languages/Spanish?rev=1.1
[Gnustep-cvs] gnustep/core/base ChangeLog
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Sheldon Gill <[EMAIL PROTECTED]>05/05/12 11:20:35 Modified files: core/base : ChangeLog Log message: spanish language localisation entry CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/ChangeLog.diff?tr1=1.2524&tr2=1.2525&r1=text&r2=text
Re: Windows port direction
efined locations for that" I assume you mean to a key in the registry, in HKEY_CURRENT_USER\Software\GNUstep or something? To be spec compliant it needs to write it's preference data to HK\Software\\ so we'd need eg HKCU\Software\GNU\Gorm\ Supporting this properly requires a different NSUserDefaults module. The amount of common code which factors out is small and leads to more confusion in my view than separate implementations. 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 Windows conventions and novelties. > Yep, it's fairly clear...you should also talk to Sheldon Gill, he's been working on various win32 things such as path handlinc recently. Yes, talk to me :-> Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Building in a separate directory
BTW, first they moved to JAM, then they internalized JAM's code into Xcode so it's not invoked as a separate process. It's possible that JAM is able to handle spaces, though maybe Apple had to modify it for this. Jam handles spaces (and a number of other things) Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Release check
Is anyone planning on adding something to the GNUstep libraries that will make them binary incompatible (i.e. compared to the current CVS)? It would be nice to start working on getting the next release out. Adding binary compatible changes is still fine, of course. I'm going to be integrating the next step of PathUtilities changes we've discussed. Also, I'm planning to propose a change so that NSSearchPath() only supports NSxxxDirectory and add GSSearchPath which supports the additional GSxxxDirectory specifiers. This would make writing portable code much easier. Perhaps we should be managing a stable branch while moving HEAD to the new binary incompatible release? Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Internal Error: The private GNUstep function to establish the argv and environment was not called
Jürgen Lorenz Simon wrote:
Hi again,
just in case I ran a debugger on the deployment machine to extract a
stacktrace:
GNUSTEP Internal Error:
The private GNUstep function to establish the argv and environment
variables was not called.
Please report the error to [EMAIL PROTECTED]
Maybe it helps to localise the problem.
For some reason, either that the code isn't executing +load or (more likely)
there is an issue with GS_FAKE_MAIN.
The easy way around this is:
main( int argc, char **argv, char **env)
{
NSProcessInfo *thisProcess;
thisProcess = [NSProcessInfo initializeWithArguments: argv
count: argc
environment: env];
}
although you might get it to work simply by using:
thisProcess = [NSProcessInfo processInfo];
The hard way is to work out why the fake main/load-initialize isn't working
right.
Regards,
Sheldon
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
[EMAIL PROTECTED] wrote:
Alex Perez has suggested using some of the funds that GNUstep has
(and/or directed donations from individuals) to fund a part-time
programmer to improve GNUstep. Some specific projects include
...
May be we could create smaller bounties for more specific stuff, here
are some ideas :
I'd like to add accessibility to the list:
http://developer.apple.com/documentation/Cocoa/Conceptual/Accessibility/AccessibilityCocoa.pdf
I think this going to be an increasingly hot issue for people deploying
applications into regulated environments such as government and
education sectors, in addition to the rather more basic interest in
making GNUstep useful to a diverse user population.
I also think Accessibility is an important addition but it is unfortunately a
rather complex topic.
{I worked with various special needs in the past and so have more experience
with accessibility than most}
The problem is compounded at the moment because there are many different
efforts to add better accessibility support to *nix, none of which are
reasonably mature.
Further, fully featured support is something that needs to be integrated into
the desktop rather than something that can be simply added to -core.
Thus, I don't think it's something we can just add to the list and attribute a
bounty to.
However, Accessibility and complex input methods are actually quite closely
related topics at the developer level. We can certainly move GNUstep closer to
the goal by working on support for diverse input methods. While this is only
part of what is required, it does get us closer and gives an immediate benefit
of better multi-lingual support which is also needed.
There are probably a few other small specific tasks we can add to the list to
prepare a better foundation for this, too.
Regards,
Sheldon
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep improvements bounty
Adrian Robert wrote: I agree with Fabien's opinion (below). People are always interested to work on new features -- it seems like the CoreData stuff for example is already well on its way even though Tiger's just out -- but it's the more thankless work like fixing bugs and filling in rarely-invoked implementations that most needs to be compensated to occur at all. Alex Perez has suggested using some of the funds that GNUstep has (and/or directed donations from individuals) to fund a part-time programmer to improve GNUstep. Some specific projects include CoreData and Predicates. Are other people interested in seeing these things added to GNUstep? I think the general idea of the improvements bounty is great. CoreData and Predicates both seem interesting are probably good candidates to figure out how to structure such bounty project. I think that CoreData, Predicates, KVO and a number of other things are actually very bad candidates. The reason is this: Community projects tend to get lots of work done in the areas which are considered interesting or which are clearly visible to others. It is the things which don't and probably won't get done which should have the bounty as incentive. Also, as the GNUstep funds and administration are very limited, I'd suggest it best that bounty tasks be small, contained and very well defined. They should be work on the -core libraries which provide benefit to large numbers of users. As there are commercial interests using GNUstep, it would be great if those companies would offer bounties for functionality they'd like. Instead of paying an internal programmer, offer the sum as a bounty with a time limit. Then there is a chance that the work is already done before your internal programmers get to the task. You can actually shorten your project timeline at the same cost without risk. I think it would be usefull to fix all bugs in AppKit / backend first see : http://savannah.gnu.org/bugs/?group=gnustep Make stable and "bugs free" all we already have should be the first priority. Agreed in principle. Other suggestions : - Icons for the default NeXTish look. - a clone of HearderViewer ( and pre-compiled headers ) - Port of WebCore I'd vote against all three of these. There are icons out there already to use. More can be done. They are quite visible and there is recognition factor in contributing them so I don't think icons are a good candidate at this stage. HeaderViewer is an app. If enough people want it, it'll happen. The functionality can come through other means anyway. There already has been quite some effort in porting WebCore and the concensus seems to be to wait for ObjC++ support in GNU gcc. Hence, WebCore will happen in time anyway. Pre-compiled header support in -make is definitely a good thing. I believe Nicola and some others have already looked into this... Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Frameworks on windows.
OTOH, similar to the workarounds we have in -make for frameworks on non-Darwin systems, we could probably make it work in conjunction with Free versions of junction command line tools. But understand this is not the relocatable framework which compiler/linker/loader handle via -F/-framework. And windows users must be educated to not attempt to remove symlinked/junctioned directories via standard tools like rm, del or the Explorer. Yes. Warning: The term Junction is not the correct term, and windows'/microsoft terminology for symlinks and hard links are known to be internally inconsistant within their own documentation. Interesting, what is the correct term? I've seen the term junction: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q205524 and multiple other places: http://www.google.com/search?hl=en&lr=&biw=819&q=junction+windows+NTFS&btnG=Search The technical functionality used under windows is a "Reparse point". The details get somewhat messy. Junction is the usual term for using the reparse point functionality to create a directory which points (path reparses) to another directory. This gives a symlink to a directory. As far as I know, the link must be absolute. I'll experiment sometime to confirm that, but I'm 80% relative paths won't work. Anyway, I don't think that trying to support symlinks under windows is the right way to go. For starters, you can't symlink to a file. Deletion is problematic. Finally, it doesn't really help get the *real* functionality we're looking for. What we want is a single directory tree for the framework. That can be done without symlinks with the loss of versioning via symlinks. The ability to locate and load the framework code is key and can be done now that -base searches the framework paths properly. The next part is properly linking programs so they activate the framework location mechanism (NSBundle). That is gcc/binutils territory. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Core release, Wed
Nicola Pero wrote: I'm mostly satisfied with the libraries now, which is to say, I don't really have any time to make any significant changes. So I'll plan on freezing the release this Wednesday. Unless there are any objections. The Windows pseudo-framework support needs more polishing ... hopefully I can do some more tomorrow (there are nice patches and suggestions pending -- thanks!). It's probably not a release-critical issue though ? I also have some windows changes changes to check in. Was planning to do that over the next couple of days. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
Gregory John Casamento wrote: GNUstep has been relatively stagnant over the last several months and it has become a cause for concern for me. I am observing the same thing and realised few reasons (ordered how they comeunder my fingers on keyboard): External issues: 1. GNUstep desperately lacks an attractor for developers Although we have Gorm and ProjectCenter, I believe we do need more to make GNUstep attractive to devs. Some debugging (think MallocDebug) tools and other things might be nice in this regard. Also, a fully working ProjectCenter would be good as well. I sort of agree with this. I feel it's more a symptom than a cause. We need better documentation and better support tools. To some degree these become self generating when the project is moving well with momentum. 2. GNUstep lacks attractor for users (this adds to the impact on 1.) We need more apps to make this happen. If you build it, they will come. Better dev environment means better dev, a precursor to the apps. Internal issues: 4. GNUstep has no project management, nor resources management, nor task management 5. GNUstep has no single achievable goal, neither short therm nor long term Both of these can be taken care of by the creation of a roadmap to show what the project is and will be doing in the future. I disagree. Completely. A roadmap is not project management. It's not resource management. It's not even task management. It's an idea of where things are going, not an implementable plan of how to get there. I do agree entirely that project management is a key issue. Probably THE issue. The size and complexity have grown beyond simple, organic organisation. You have already mentioned some solutions that I have removed from this email, as they are already being discussed. Your suggestions address mainly points 2,3 and somehow point 1. But there is still problem 4 and 5. GNUstep developers and friends are pulling the rope on the same end, but to thousands of different directions :-) This reminds me a story for children by Czech writer Josef Capek in a book Of Dog and Cat. Dog (the dog) and Cat (the cat) wanted to bake a cake. They were putting in a pot everything they liked and they thought that would be good to have in the cake... "I like this, so I add it there" "Ok, that would be fine. I'll at that, because I like that and it is good" ... The cake was mixture only of "all good things", however at the end it was uneatable. We are baking similar cake too... Lack of larger picture, roadmap and kind of management affects development. Also lack of requirements specifications is making development of GNUstep much difficult and slow. Potential developers do not know what should be implemented, not speaking about how it should be developed. From management point of view, first step that should be done in GNUstep is detailed roadmap with very good task breakdown and expressend depencencies. For this I would suggest to either revive the 'Tasks' on savannah or use Wiki. With savannah one would have better task tracking, however on the wiki there would be better public visibility and accessibility, even it would be in a plain- text. I would vote for the wiki option. I'd vote for savannah unless we have a better solution. The one I'd really like to see is one written around oOGO/gsweb... Tasks should be laid in a tree-like structure with good breakdown. 'CORBA' is an example of very bad task. Yes, one should start with taks like 'Windows support', but then it should be broken into 'Installation', 'Pasteboard', 'UI', 'Distributed Objects', etc. It is still not enough, because neither current nor new developer would know, what should be implemented for 'pasteboard'. Therefore one who knows should write: 'implement handling of type XY this or that way'. Now back to the project, people, resources and time. Many, if not all, core gnustep developers complain that they do not have time. Ok, me neither. But I ask: "WHO IS GOING TO IMPLEMENT MISSING GNUSTEP PARTS, IF THE ONLY KNOW-HOW HOLDER IS YOU?". Answer is: noone. Solution: GET THE KNOW HOW OUT OF YOUR HEAD AND SHARE IT!. Please, if every core developer was able to find just a little bit of time to write unordered bulleted list of his observations or knowledge about GNUstep that would be really helpful. And most importantly, write what is missing. GNUstep developers do not even know what they do not know, not to say that they do not know what they do not know and they need to know. This sort of thing would be very useful. If you take a look at NSTimeZone there is a lengthy comments section at the start which talks about the module and what it does. I wrote that original lengthy spiel. I should contribute such discussions to other modules. I'd say, though, that a better solution is to identify those with the knowledge and interest/dedication for a particular modul
Re: NSSearchPathForDirectoriesInDomains and non-existing directories
Andriy Gapon wrote: Let me shoot the question first - what is the rationale behind NSSearchPathForDirectoriesInDomains not returning directory name if the directory does not exist ? Esp. so if NSUserDomainMask is used ? This is the way the function was defined to work a long time ago. In other words, it behaves as specified. The idea in general terms is that you are asking for a location. If that location doesn't exist, it returns rather than an exception. The location may not exist because you're running on an old or new version where it doesn't exist anymore. Things change. Calling code is supposed to know and respect this. In my opinion what NSSearchPathForDirectoriesInDomains() does now is incorrect. I don't have an opportunity to verify how this function behaves in original NeXTStep or how it behaves in OS X framework, but I think GNUstep behavior is unreasonable. I see two possible ways of improving NSSearchPathForDirectoriesInDomains(): 1. just return the names and let calling code worry if the directories actually exist 2. try to create non-existing directories in the list and only if that fails that remove them from the list I personally am torn between simplicity and elegance of #1 and user-friendliness of #2. I think you've mis-diagnosed the behaviour problem. It isn't in NSSearchPath() but rather the calling code. Creation of a path isn't and shouldn't be the responsibility of NSSearchPath(). That needs to be handled elsewhere. Generally it is, by the way. There is some sense in (1) but the question arises: "what do you do when the specified directory doesn't make sense on the current system?" You'd end up needing to handle an exception or error return anyway. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: "Desktop bundles" and host-platform interfaces
Peter Cooper wrote: Hi everyone I was going to update the wiki with some thoughts about desktop bundles and host-platform service interfaces, but it's still locked. Instead, the dev mailing list will get spammed - it might be useful to discuss anyway. There's been some discussion about the need for "desktop bundles" in GNUstep. They are intended to support using GNUstep apps within a native desktop environment like GNOME, KDE, Windows and MacOSX. I guess these bundles will be tied in to some kind of UI theme, too. Probably will be tied to a UI theme eventually. Initially much of the work is at a lower level. I think it's a good idea, it'd be nice to be able to use GNUstep and the development tools to create native-like apps for other platforms. Even better, doing this might make a GNUstep-native environment richer, by creating a GNUstep-native bundle that enables the same kind of functionality in a GNUstep desktop kind of way. This is where things get murky. What's a "GNUstep desktop kind of way"? I believe that the key initial direction is a set of API/Classes which appropriately provide the underlying mechanisms or re-target existing ones so that the platform specific approach is well integrated. My view is that an environment discovery mechanism (ala Gestalt) is the right starting point. So applications can ask "hasX" or "supportsX" questions. The key areas I can think of that would benefit from a bundle of prebuilt standard dialogs, integrated host-desktop dialogs, controls and GNUstep-like APIs are: * disk and file management - managing volumes - platform/filesystem independent capacity, read-only/read-write status, formatting, inserting, ejecting - utilising local shortcut schemes, special folders, VFS schemes etc - integration into local indexing services I agree that applications should be able to cleanly access this functionality. Not so sure about UI facilities. They'd be per application rather than provided by a bundle. * misc hardware - power management integration - battery data - screen topology (how many? what layout?), bit-depth and blanking - local printer services - consumer electronics services (cameras, music players, home entertainment devices) * data, IPC and helper apps - integration into local cut and paste services where not already operational, or where extra functionality exists - use of local calendar, identity (vCard-like), authenication, privilege-escalation, and mail services - messaging, voice and video services - integration of local IPC types where appropriate into GS mechanisms - use of and registration into local MIME and file type mappings - start and stop local services * networking - interface configuration - interface authentication - profiles - remote desktop services - web and internet services (proxies, system-wide aggregators) * internationalisation and localisation - integration into local localisation services for currency symbols, date formats, sort orders, timezone name display-names, well-known filesystem locations... - keyboard layout etc There is a lot of work in -core still needed in this area. * assistive and automation services - local screen readers and assistance services - local alternative data entry systems - proxies for local automation services The idea would be first to be able to harvest these things from the local system, so that our application that wishes to appear native can use local services, provide expected functionality, display the appropriate local directory names depending on the language settings of the user, battery charge status etc. In some cases, there are new Cocoa classes that would be well-suited to deliver this functionality to a GNUstep app, and where a desktop bundle could provide UI wrapping for it. In other cases, it'd be necessary to create some kind of well-thought-out GS extension classes I guess. Definitely. There are actually quite a few extension classes required to encapsulate all the above. For some of it the design work needed is actually quite extensive. For example, network authentication and authorisation would be a big design task unless you go with Open Directory. Messaging is an extensive field of much interest but also debate. It gets too close to Collaboration and GroupWare... You'd probably need a backend bundle - GNOME runs on a large number of platforms, all of which have different ways of doing power-management, for example. KDE and a native GNUstep desktop are in the same boat - it seems sensible to create common backends for them for Linux, the BSDs, etc. Some of this is being addressed by the FreeDesktop standards. I personally think some of their solutions aren't what they should be but until I put up I'll keep quiet. Is anyone doing any work on these things at this point? Umm... yes. Me. Mostly for Win32 at this point because it's the outlyer but also because it
Re: GNUstep ROADMAP
Richard Frith-Macdonald wrote:
1. it says current base/make/back ... but what about ms-windows support
... I'm guessing we want base/make/back fixes/improvements for windows
as it's not nearly such a good state as unix-style systems. I'm not
sure this is a 1.1 issue rather than 1.0
In my opinion it's definitely a 1.0 issue. A short explanation why:
* it's high-lighting assumptions and specifications made in the codebase for
unix generally and window maker specifically.
* focus issues are, to varying degrees, problems on KDE, GNOME etc as well
* add to that window manager interaction. We're not doing well with other
window managers.
I'd but back with gui because the two really do go together. We should consider
base, make and GUI as three separate categories and focus on what needs to be
done on each.
This also ignores the fact that window manager interaction (focus in
particular) is undoubtedly the biggest problem with current apps, and
is a backend issue at least as much as a gui issue.
Hear, hear!
2. gui seems wildly ambitious (complete coding on all existing classes) .
I'm not sure what 'improve printing support' entails
The 'fix major bugs' is obviously required, but we should decide on
what those bugs are
I haven't heard anyone suggesting removal of classes before, and I
don't approve of the idea ... rather we should have *big* warnings
about works in progress so that people don't try to use them unless
they are also willing to work on improving them. (ie clear information
in the docs and warnings generated at runtime).
"Complete coding on all existing classes."
"Remove any classes which are not going to be finished for or included in the
1.0 release."
These two seem to be contradictory: we'll complete everything except those we
don't be completing which we'll remove instead so we can say its all complete.
I think the map should really be *much* more specific about what needs to be
done:
- Documentation
- alpha/compositing support
- themes
- panel auto-sizing and layout
- architectural changes to improve platform/desktop support work
Breakup of gui and base into component libraries ... I've never heard
of this and haven't seen anything saying why it would be at all
desirable, let alone worth making into a target.
Well I can see why some things may be worth separating out. For example,
Openstep actually had a separate pdo library. Headers in Foundation, linking
and using not a problem. It could help contain areas of functionality. This may
help in a few ways technically, but also might make maintenance easier in that
we could allocate a maintainer to a smaller code-base. It may also encourage
competing implementations or people assisting in the more specific arenas of
interest to them. Right now trying to get involved is somewhat daunting because
of the size and complexity of the libraries.
I definitely think that the IconApp (aka 'fiend') code should be entirely
separated out and become a loadable-bundle/whatever. It is NeXT desktop
specific and should be packaged accordingly. Just as other "features" may be
specific to other desktop environments.
I can see some cause for separating parts of image support so that the imaging
can rely on different libraries. More front-end/back-end stuff.
Some are interested in, for example, NSNetService and friends. We should be
able to add those in as base extensions.
Anyway, I don't remember any proposals being put forward and this is definitely
a dicussion for a different thread.
Make GNUstep more compliant with the FHS as an option ... this ought to
be quite easy ... so why not make it part of 1.0 if it's actually a
good 'selling' point?
I've done much on this. Some parts are easier but we can get a whole lot more
compliant without breakage or significant inconvenience. The level of
compliance we can achieve is pretty close to Debian.
{If we can make it there we can make it anywhere...}
The only problem in doing this is the amount of configuration involved to
tailor the installation. My idea was always for this to be for package
maintainers ony.
Again, specifics should be a different thread.
Better Windows support ... yes ... but we need to get windows users to
define what they need improving
I have a long list (of not just my own items) so I guess I should put together
the "Road to Windows"?
Regards,
Sheldon
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: DO compatibility with Apple DO
Jiva DeVoe wrote: Yeah, the problem is, you'd have to be SURE Apple was using the XML format for all DO operations - and I'd bet you couldn't do that. Oh well. Again, sorry for bringing up a topic that's in the FAQ. Actually, although quite a challenge I think it should be possible get a reasonable degree of inter-operability by installing a daemon on MacOS which will do GDO over the wire and call out to PDO... Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Rumor Mill: Apple Considering Revival of YellowBox (??)
Gregory John Casamento wrote: As many of you may have heard, there is a rumor floating around which indicates that Apple is considering reviving YellowBox, under the codename "Dharma." We have had an opportunity up until now to port applications from Cocoa to Windows using GNUstep. If Apple comes out with YellowBox, that door will be vitually closed to us as people will naturally go to Apple for that solution. If we can beat Apple to it and get a viable system going on Windows prior to Apple's release of Dharma/YellowBox, that could be a major coup for GNUstep. The need for a more complete environment on Windows === Now that Gorm is working properly under Windows, it's time to start thinking about bringing some of the other apps over as well. ProjectCenter - A significant blocker to getting ProjectCenter working on Windows at the moment is the fact that it uses frameworks. I believe that ProjectCenter should use libraries for greater portability, until it becomes possible for users to build using frameworks on Windows. I'm not sure this is the way to go. I think we can get better framework support on windows in the near term with some dedicated effort which would provide a bigger payoff than re-factoring PC to use bundles/libraries. At the momement, we have findframeworks() added. That gives us the run-time support required to locate the shared library code and load it. So I see the problem as really being about "building". Windows Theme - We need to get a windows theme prepared so that GUI will blend in better with Windows applications. Also, we need to make it so that menus are attached to the windows and not free floating. Yes, this is very important and I'm currently working on it. My view on Menus is that we should separate menu handling between -gui and -back. The idea being that NeXT-style menus are alien not only to windows but GNOME and KDE as well. Then there are those who wish to experiment with circular menus etc. One other thing that is needed is another installer which allows the user to install these applications without needing to compile them. Umm.. maybe not? Once an application is compiled and prepared for distribution it should run from where-ever it is. If the application is complex enough to require installation into separate areas (such as shared frameworks) then we should be using conventional windows installers. These are just some thoughts I've been having along these lines... if anyone has anything to add, please let me know. There are still many bugs/issues... * Pop-up menus are slow, don't scroll * Focus bugs * Apps compiled to run in Console sub-system rather than GUI * problems running modal panels * imaging compositing * icon in taskbar and so on. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: CVS changes
Adam Fedor wrote: People have complained at various times about the CVS version of GNUstep being unstable. I've had various ideas for fixing this, but I think my best one is this: Don't ever tell some one they should use the CVS version due to a bug. If it really is an important problem, I will make a patch release of the library that includes a fix, otherwise, I try to make releases every month or two anyway, so that is not that long to wait for less important fixes. Might I make a suggestion? How about a 1.11.2-stable (or whatever) branch, open only for bug fixes. Then it'd be easy for you to make minor releases very regularly and have more time to prepare (iron out issues in) major releases. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gorm/Nib compability progress
Fred Kiefer wrote: I am deeply impressed on what you achieved here. Hear! Hear! Now I am looking forward to see all this show up in the standard GNUstep CVS branch. As are we all. I just have to add one word of caution. Before we ever change Gorm to use an XML based format, we should make sure, we have an XML parser for all environments. Our current one will only work if libXML is present, which seems to be a problem on Windows. Again in myStep there could be a solution to this, as hns wrote a simple XML parser for his MIB files. I hope we are able to integrate this, as soon as the copyright assignment is sorted out. I believe, Greg, you've expressed a desire to stay with the .gorm format as preferred for now and I think that is a good way to go. The only reason to move to an XML format would be to support Apple nibs. Apple will be using XML because it opens the format up for their developers. Ours is already open ;) libXML compiles and runs on windows (2.6.22) so its looking good. Base detects it and compiles fine. I haven't tested it enough to be happy yet which is why I've not said much about it. The short form, XML support in GNUstep on Windows is there. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Repository change to SVN, Jan 28th
Fred Kiefer wrote: I also think that with the new possibilities of SVN there come a few more rules that we need to set up and follow. We expect that SVN will make it easier to have multiple branches with actual development going on. Now what will be the rules for merging this branches back into the main trunk? At work we are using ClearCase and have rather complicated procedures that have to be followed to make this step save. Something simpler might be enough for GNUstep. At least all changes from the trunk need to be merged down first, conficts resolved and the code tested. Then a review could happen, before the changes get actually merged. Actually, I think Fred has raised a good point here. We do, I think, need some clarification about branches and merging back to trunk. A few additional rules and guidelines may be useful. I've some questions: - are we going to stick with the SVN recommended 'trunk', 'branch' and 'tag' - how are branches to be named? What about sub-branches? - how are developers going to communicate about branches and what's going on in them? - what goes into tag? When? - Are we going to import more vendor trees? (like ffcall, portaudio etc) Things to think about. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Repository change to SVN, Jan 28th
David Ayers wrote: Sheldon Gill schrieb: Fred Kiefer wrote: [snip] - are we going to stick with the SVN recommended 'trunk', 'branch' and 'tag' I would like to see this. So would I. The thing I was thinking about is experimental or proof-of-concept type work. At the moment it seems that mostly goes on in private sandboxes. It may be beneficial to bring some of that work into the open? - how are branches to be named? What about sub-branches? I believe there were some suggestions before. I had no objections but also no strong feelings. Neither do I but I feel a set of guidelines would be a good thing. - how are developers going to communicate about branches and what's going on in them? I would suggest the Wiki. I'm all for that. Maybe with occasional announcements to the -dev list. - what goes into tag? When? You mean other than releases? Well since we have defined repository states through revision numbers, I can't think of any necessity for more tags. It's not like gnustep is seeing the kind of development activity like, say, GCC. But maybe you have something specific in mind? Main releases are obvious. I'm wondering about branch snapshots. - Are we going to import more vendor trees? (like ffcall, portaudio etc) I think we should keep anything not FSF assigned in a separate repository so we have clear boundaries from where we can blindly copy-and-paste code. Other than that I think there should be a dedicated maintainer(s) for any external vendor tree who will keep them up to date. I'm not sure we need a separate repository. Wouldn't a vendor directory tree would make the boundary equally clear? Other than that, I'm in agreement with this. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Problems with automatic start of gdnc, gpbs, and gdomap on Linux...
Greg, Gregory John Casamento wrote: The subject basically says it. When I log in, it's reporting that it had trouble starting gdnc. Is anyone else having this problem? Could you please let us know what the messages/logs say? I take it you're running HEAD ? Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Repository change to SVN, Jan 28th
David Ayers wrote: Sheldon Gill schrieb: David Ayers wrote: You mean other than releases? Well since we have defined repository states through revision numbers, I can't think of any necessity for more tags. It's not like gnustep is seeing the kind of development activity like, say, GCC. But maybe you have something specific in mind? Main releases are obvious. I'm wondering about branch snapshots. Not sure why you'd want a snapshot of a branch unless your releasing from branch (as in dedicated release branches with bugfix releases à la GCC). I was thinking of two things here: One is branch releases where a branch is somewhat experimental. This would help with testing and review. The other is bugfix releases, ala GCC. - Are we going to import more vendor trees? (like ffcall, portaudio etc) I think we should keep anything not FSF assigned in a separate repository so we have clear boundaries from where we can blindly copy-and-paste code. Other than that I think there should be a dedicated maintainer(s) for any external vendor tree who will keep them up to date. I'm not sure we need a separate repository. Wouldn't a vendor directory tree would make the boundary equally clear? Other than that, I'm in agreement with this. IMO the copyright assignment boundary should be pretty clear especially if we have all projects at top level as was originally proposed, IIRC. I'm still in favor of a separate repository, but that's just my opinion. Same or separate, as long as the boundary and use is clear. I wasn't thinking of having vendor items mixed in at the top level with the rest of GNUstep items. Rather a separate directory, so it's apparent they are in the Vendor tree. (Or whatever we choose to call it) Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
Richard Frith-Macdonald wrote: On 23 Jan 2006, at 21:36, David Ayers wrote: Richard Frith-Macdonald schrieb: We could finish getting the NSWorkspace class to do what it was originally designed to do ... provide the list of launched apps as supplied by the workspace manager. That would be a small modification to NSWorkspace and to GWorkspace. However, we would want some fallback option for if/when GWorkspace is not running. Perhaps a minimal workspace manager daemon, or perhaps NSWorkspace could write to a small database (eg a plist file in a temporary directory) to maintain the state information. The latter has the advantages of not requiring an additional daemon to run (I have no problem with daemons, but I know many people have objections to them) and is persistent if the workspace manager is restarted (we need that). The former has the advantages that it would provide a testbed and reference implementation for workspace managers. I suppose we could do both. For what its worth, I think the current approach within -core is right. Minimal NSWorkspace. Keep it lean. The functionality should be implemented by the desktop shell. That'd be: - GWorkspace/WindowMaker for most - For KDE, there'll need to be a different implementation - Win32 needs to talk to the Shell (Explorer) For KDE & Win32 there is no need for another daemon as there already is one running. I'm pretty sure there is a GNOMEish solution, too. I could very well be missing something obvious but I seems to me that gdnc would be a good candidate to provide this service. If we want to put the functionality into an existing daemon, I think gpbs would be the best option, as it is part of the gui/back libraries (ie related to applications) while gdnc provides a service for the base library. I really think the functionality shouldn't be incorporated into either daemon but left for a real NSWorkspace implementation appropriate for the particular running desktop. However, if we want to provide a reference implementation that developers of workspace managers can look at, I think a standalone process would be better than attaching the functionality to an existing daemon... and if we don't want to do that, my preference would be not to bother at all ... just use an on-disk database of the information we need, and modify GWorkspace as our standard workspace manager. A reference/sample implementation is definitely a good idea. I also agree that modifying GWorkspace is the right way... Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
System & System Extension color lists
Unification of the System color list To support better theming and user configurability generally it is desirable for users to be able to specify the use of colors. Currently this is done through the System color list, which is created at initialisation through hardcode values or by loading a user created list. GSToolbar uses a "System extension" to add it's two color values. Is there any reason why we can't unite these additions into the System color list? Saving of the color list At the moment, in NSColor.m -> initSystemColors() If there is no previously saved System color list, it will automatically write one out. I'd like to change this. That is: if there is no previously saved list, we don't simply write a default one out but rather rely on the initialiser every time. Any objections? Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: System & System Extension color lists
Adrian Robert wrote: Saving of the color list At the moment, in NSColor.m -> initSystemColors() If there is no previously saved System color list, it will automatically write one out. I'd like to change this. That is: if there is no previously saved list, we don't simply write a default one out but rather rely on the initialiser every time. What rationale? (Playing devil's advocate, I can imagine the writing of the default one speeding future startups and being useful to give the user something to edit, although clearly things should move towards a Preferences.app style approach to customization.) 1) Users have complained about creating files, seemingly "unnecessarily". If they're relying on the default colors, why is it 'making a mess' (minor) 2) It writes to the user specific color lists. It is then impossible to tell if it is a list the user decided to use or one the system simply wrote by its own accord. 3) Many environments have system colors defined elsewhere. Think KDE, GNOME and Win32. WindowMaker also has some. Its desirable for GNUstep to 'play nice' on those systems and rely on externally supplied lists. 4) Those other environments support changing colors and all applications responding. With current GNUstep, it becomes difficult to support this nicely. Essentially we either clobber user settings or not. Considering your "pro" items: a) Giving the user something to edit shouldn't be a "System.clr" text file but an application or tool which will help them do it. Most users aren't happy playing with separate numbers for RGB values in text format, IMHO. b) Giving the user something to edit as a "System.clr" file is easy. Give them an URL c) If it's a good idea in a particular configuration to speed things up then it is really a packaging issue. In this case, provide a default System.clr installed in SYSTEM_ROOT\Library\Colors (Happily engaging in debate...) Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: svn+ssh on mingw32?
Richard Frith-Macdonald wrote: Has anyone managed to get svn+ssh working on windowing in the ming32 environment yet? Well, I have. At least, I've fetched the code without issue over ssh using my key. Actually, without issue isn't strictly true: svn co svn+step://svn.gna.org/svn/gnustep/devmodules/core returned an error after checking out the first level: couldn't find external gui. That's not a windows problem, though. After installing svn-win32-1.3.0 to use from the msys command line I get 'svn: Connection closed unexpectedly' > My ssh setup works fine for me normally (I was using it to access the CVS repository without trouble). > > I have tried adding an ssh key without password protection so that I > know that svn won't be confused by ssh wanting a password. > I have told ssh what username to use when contacting gna.org. > > My ssh config file says - > > Protocol 2 > Host svn.gna.org > User rfm > IdentityFile ~/.ssh/insecure > I'd suggest you check it. Specifically with the gna server. Like this: ssh -l rfm svn.gna.org (modify if you're using some other command/tool) If you've got it set up right, it'll ask you for the passphrase to your key. Or if you're using an unprotected key, it'll go through ready for a command. If this bit won't work, there's no point going further. Any ideas? It would be a pity if the move to subversion means we stop doing windows development. It would seem to me that the problem is your ssh session isn't being established with the right credentials or that the key isn't registered. The "Connection closed unexpectedly" message is the tunnel being closed prematurely. Oh... did you tell gna.org about your new key? Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: svn+ssh on mingw32?
Richard Frith-Macdonald wrote: I expect so ... but the question is ... why? My ssh connection works fine. svn+ssh works fine on linux. So the issue must be something to do with the subversion client ... my guess is it's not picking up the ssh configuration from ~/.ssh for some reason, but I haven't figured out how/why that can be the case. I also don't see how a problem with the command-line client could also effect the TortoiseSVN stuff ... which I configured completely independently using Putty stuff rather than OpenSSH stuff. That's two different ssh implementations being used and both giving the same error. Maybe this will help: export SVN_SSH=ssh -l rfm -i ~/.ssh/your_key Have you checked that using plink gets you an authenticated connection? Incidentally, are you running any firewall software on your machine? I've come across some which rely on the process name for permissions. I've also come across virus-scanner/security tools which don't play too nicely. Suspect them as well. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: svn+ssh on mingw32?
Richard Frith-Macdonald wrote: On 8 Feb 2006, at 10:45, Sheldon Gill wrote: Richard Frith-Macdonald wrote: I expect so ... but the question is ... why? My ssh connection works fine. svn+ssh works fine on linux. So the issue must be something to do with the subversion client ... my guess is it's not picking up the ssh configuration from ~/.ssh for some reason, but I haven't figured out how/why that can be the case. I also don't see how a problem with the command-line client could also effect the TortoiseSVN stuff ... which I configured completely independently using Putty stuff rather than OpenSSH stuff. That's two different ssh implementations being used and both giving the same error. Maybe this will help: export SVN_SSH=ssh -l rfm -i ~/.ssh/your_key Thanks ... but I've just now got it working, and I'm inclined to stick with what I've got. I edited 'C:/Documents and Settings/richard/Application Data/Subversion/config' and added a line to explicitly specify the path to my mingw32/msys copy of ssh ... 'ssh = $SVN_SSH C:/msys/1.0/bin/ssh.exe' Actually, editing [tunnels] in subversion config was my next suggestion. For what its worth, here's a summary for getting PuTTY going: * download and install svn client * download and install putty, plink, pageant... Make sure both are in your path somewhere. I like \Program Files\Bin\ * Generate a key using puttygen (It can also import existing keys from elsewhere...) Save it somewhere as * Tell GNA.org about the key and wait an hour * Check ssh access plink -v -ssh -l -i svn.gna.org * Edit Subversion configuration %USERPROFILE%\Application Data\Subversion\config [tunnels] putty = plink -ssh -l * Launch pageant and add your key * Check subversion access svn list svn+putty://svn.gna.org/svn/gnustep Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: svn+ssh on mingw32?
Andrew Ruder wrote: svn list svn+putty://svn.gna.org/svn/gnustep You'll probably want to figure out how to get it so you can checkout with svn+ssh. The /devmodules is configured such that it checks the externals out with svn+ssh. I got windows working and booted into this morning, when I get home this evening, hopefully I am able to check things out (no pun intended) ;) To make the above work with /devmodules externals property definitions you simply need to change the Subversion configuration file: [tunnels] ssh = $SVN_SSH plink -ssh -l The first tunnel definition I gave was because I've got multiple ssh methods available. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Subversion problems on windows
Derek Zhou wrote: Most sane Unix editors can cope with windows CR/LF automatically too; as long as no one is mixing styles in the same file, everyone should be fine. If the style is mixed up within the same file, even "eol-native" can not guranty to do the right thing anyway. My suggestion is the origin author of a file decides which style this file should be, be it windows or unix or mac, and everybody just follow the convention within this file. The trouble with using the "svn:eol-native" property is that it makes subversion do a line conversion. So it does the unix2dos or dos2unix conversion. So your suggestion of letting the author decide and everybody else just stick with that can only be done if the property is *not* set. Otherwise you check out a file and it's always native to the platform you checked out on. Having to keep track of which file is ascii and which file is binary is tedious. Agreed and there is no need to do that if we delete the propery. Note though, that we'd otherwise need to keep track of which file is considered 'text' by subversion but is encoded non-ascii. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
Richard Frith-Macdonald wrote:
On 23 Feb 2006, at 01:04, Gregory John Casamento wrote:
Actually ... I'm getting the impression that the best thing to do might
just be not warn about missing external resources if the library is
installed in a path other than System/Library/Libraries
Might I suggest:
library messages (base & gui) are assigned a level:
Debug
Technical
Informational
Warning
Error
Critical
and output is according to chosen level.
If the library is looking for a resource and can't find it
If the problem means execution can't continue
report as Error
If the problem is likely to cause execution failure
report as Warning
Otherwise
report as Technical
{Exact details, of course, to be agreed...}
Regards,
Sheldon
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
Richard Frith-Macdonald wrote: On 25 Feb 2006, at 04:37, Sheldon Gill wrote: Richard Frith-Macdonald wrote: On 23 Feb 2006, at 01:04, Gregory John Casamento wrote: [snip] So, only four categories rather than six ... even so, I think NSWarnLog() is hardly ever used ... I think it's really, really hard to assign some messages to particular categories ... for anything which is not a fatal error and is not clearly for debugging purposes, it's horribly different to classify, because what is appropriate usually depends on the audiance/user and what they are trying to do with the library. I think its actually much easier to classify than you thing. The audience to consider is "run-of-the-mill" user running a packaged installation. After all, this is the target audience in the end for just about everyone. In my experience, most such end users only want logs containing bad things they really need to know about. Less, rather than more. Power users and developers have the savvy to up their logging level. They can also be presumed to understand more detail/technical info. However, an audit would be good ... I suspect a number of NSLog() calls should be NSWarnLog() or even NSDebugLog() Basically what I'm getting at. Problem is, at the moment there isn't any rule or guideline about how to classify such messages. The problem we have with NSWarnLog() is that it is being used for information level messages rather than warning/alert level messages. It should be more like GSInfoLog() to be clear. I'd expect most packaged installs to have such messages off. In my view there are lots of messages which need to be sorted. I would rather change them after we have some general agreement on categorisation. What I was referring to in an earlier email is the idea that in some circumstances (a normal install) missing resource files are a real oddity and mean that the program won't behave as expected ... which may well constitute a failure, but in other circumstances (deliberately installed without resources as a standalone library) you could assume that the lack of locatable resources was intentional, so any program using the library presumably expects the changed behavior and it is not a failure. Thinking more about it, this is probably not a good idea to infer from library location. Great. With you on that. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_CONFIG_FILE value ('/etc/GNUstep/GNUstep.conf') is not an absolute path
Tom Koelman wrote:
Hi,
I am fixing the Windows Installer with regard to the GNUstep.conf
file. I am building base 1.11.2 and gui 0.10.2.
I use the following incantations:
In the directory with source of GNUstep make:
cd /gnustep-source/make
./configure --prefix=$GNUSTEP_INSTALL_DIR
--with-config-file=$GNUSTEP_INSTALL_DIR/GNUstep.conf
make install
[...] Build ffcall [...]
# Build and install the base library itself
cd /gnustep-source/base
./configure --disable-xml --with-config-file=$GNUSTEP_INSTALL_DIR/GNUstep.conf
make install messages=yes warn=no
Now, if I run the defaults.exe program or some other GNUstep using
program I get the following:
2006-03-06 14:57:21.708 defaults.exe[3680] GNUSTEP_CONFIG_FILE value
('/etc/GNUstep/GNUstep.conf') is not an absolute path. Please rebuild
GNUstep-base specifying a valid path to the config file.
What do I do wrong? As far as I can tell I already build GNUstep-base
specifying a valid path to the config file.
If you have specified a file and it's been picked up correctly you will find
your definition in:
core/base/Source/config.h
I suggest you check that first.
Are you using the *release* of base 1.11.2 or a later CVS version?
Regards,
Sheldon
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Config updates
Nicola Pero wrote:
I committed some changes to gnustep-make that should fix a few remaining
issues in the config system. There are a few things worth nothing.
**1. No more need to source GNUstep.sh :-)
It works for me, might need more work to work for everyone I guess ;-)
Anyway in the standard flattened/no-multi-arch case, once I add the
gnustep dirs
to /etc/ld.so.conf and to PATH (I'm on GNU), I can now compile stuff by
just doing:
export GNUSTEP_MAKEFILES=/opt/gnustep/System/Library/Makefiles
make
No more need to source GNUstep.sh :-)
(hope it works for you as well, if not, let me know!)
I'm afraid that won't work on MS-Windows. For starters, no /etc/ld.so.conf
Also, I'm not that keen on adding all those dirs to either ld.so.conf or my
PATH.
IMHO there is a better solution for those who don't want to source GNUstep.sh
and that is to place a command on their path which sets up the environment and
evokes make.
Something like this:
#!/bin/sh
# Command to make GNUstep applications
# Sets up the environment correctly and then
# invokes make.
. /usr/shared/GNUstep/Makefiles/GNUstep.sh
make $@
That works everywhere and makes it easy to change things when needed. Doesn't
require any mods to ld.so.conf nor changes to the existing PATH
I've put mine into /usr/bin/ so things are sweet. No sourcing GNUstep.sh, no
need to mod the environment nor edit my .bashrc or profile. Nada.
Also, your solution *still* requires
export GNUSTEP_MAKEFILES=
which sort of defeats the purpose in my view because you still need a
preliminary step before you can build.
**2. Each library-combo needs to be configured separately
Second, Richard started a change to move the gnustep-make config into a
library-combo subdir,
which I've now completed ... it has a few implications:
1. you can configure different library-combos to use different compilers
with different flags;
I assume this was the main reason behind the change (presumably it helps
with apple-apple-apple
vs gnu-gnu-gnu on Mac OS X ?)
Sound in theory.
2. if you haven't configured a library-combo, you can no longer use it.
For example, if you plan on
using both gnu-gnu-gnu and gnu-ld-nil, you need to do
./configure --with-library-combo=gnu-gnu-gnu --disable-flattened
make
su -c 'make install'
./configure --with-library-combo=gnu-ld-nil --disable-flattened
make
su -c 'make install'
The second one is needed because it will install
GNUSTEP_MAKEFILES/ix86/linux-gnu/gnu-fd-nil/config.make.
If you try to compile using a library-combo that wasn't configured, it
won't work. This is because
each one has got its own CC, OPTFLAGS, etc flags now. Hmmm.
Hmm.. won't this will mean that all Headers will actually be in
$GNUSTEP_SYSTEM_ROOT/Library/Headers/${ac_cv_library_combo}
right? So we'd have like
/usr/GNUstep/System/Library/Headers/gnu-gnu-gnu/Foundation/
As long as flattened continues to be supported.
I'll have to look at the flags issue sometime.
Regards,
Sheldon
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Compiling and running a test tool
Hi, I can compile and run a test tool consisting of a single source file by invoking "make test" using a GNUmakefile like this include $(GNUSTEP_MAKEFILES)/common.make foo_OBJC_FILES=foo.m include $(GNUSTEP_MAKEFILES)/test-tool.make test: ./obj/foo which is pretty sweet. Trouble is, how do you extend this to a test tool which is spread over multiple source files? Or a test tool which depends on another tool build beforehand? The obvious thing to try was: thing_OBJC_FILES=foo.m bar.m include $(GNUSTEP_MAKEFILES)/test-tool.make test: ./obj/thing but that doesn't work at all. Changing that depends to test: thing means it will all compile and link sweetly but won't be run. It's getting late and my brain is slow. Help anyone? Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compiling and running a test tool
Doh! Sorry to reply to my own post. Sorry to post in the first place. It is late and my brain is slow. I've sorted it now. *mutters about TABs in makefiles* Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: make help
Nicola Pero wrote: I was thinking of adding a little bit of inline help for gnustep-make. What's the best way ? I was thinking of adding a target like $> make help This is gnustep-make 1.13.0. Most common targets: make all (builds) make install (installs) make uninstall (uninstalls) make clean (deletes built files) make distclean (deletes all built files) make dist (creates a .tar.gz of the software sources) Most common options that can be used with any of the targets: debug=no (turns off generation of debug symbols) strip=yes (strips executables and objects before installing) shared=no (builds static executable and objects) messages=yes (prints verbosely all commands being executed) GNUSTEP_INSTALLATION_DIR=/usr/GNUstep/System (installs in the specified dir) $> I'm all for adding more documentation and help... but... please *don't* make it a target! $> make help is used to generate application help files. > Anyone has got a better idea ? The obvious one would be --help but that'd invoke 'make's own, of course ;) Here are some other ideas you could use: info helpme summary options gnustep-make-help shortform or make it an option info=yes summary=yes shortform=yes Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
Nicola Pero wrote: Would it be an idea to have an option that decides what kind of tree is going to be used like: GNUSTEP_FS_STRUCTURE=[FHS|GNUSTEP|WINDOWS|SOLARIS] We're not far from that ;-) ... that option will be used when configuring gnustep-make. It is -base which decides what goes where so we shouldn't we really be configuring base, not -make? Decoupling the dependencies is a good thing, IMHO. We just need to save the configured filesystem structure in GNUstep.conf, and use it to set GNUSTEP_APPS etc. in common.make, and we're almost done (except that a few things, like GNUSTEP_INSTALLATION_DIR, will no longer work in that context). ;-) Then every application, at launch time, must set up the whole fs structure? >> And then GNUSTEP_INSTALLATION_DIR decides where the root is, maybe it should be called GNUSTEP_FS_ROOT, like in GNUSTEP_FS_ROOT=[/usr/GNUstep/System|/usr/GNUstep/Local|/usr|/usr/local|/opt] Why not GNUSTEP_INSTALLATION_DOMAIN then, which is an 'abstract' definition of where things should be installed ? gnustep-make would then map it to the local reality. :-) For consideration, isn't GNUSTEP_INSTALLATION_DOMAIN a little too confusing? I'd prefer something a little more like: GNUSTEP_INSTALLATION_DIR (we'd have to change some -make internals) GNUSTEP_INSTALL_INTO GNUSTEP_INSTALL_DESTINATION or perhaps we should be thinking more along packaging lines... GNUSTEP_PACKAGE_LOCATION Packagers can easily add a line to their makefile or preamble this way... Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
Nicola Pero wrote: Would it be an idea to have an option that decides what kind of tree is going to be used like: GNUSTEP_FS_STRUCTURE=[FHS|GNUSTEP|WINDOWS|SOLARIS] We're not far from that ;-) ... that option will be used when configuring gnustep-make. It is -base which decides what goes where so we shouldn't we really be configuring base, not -make? Decoupling the dependencies is a good thing, IMHO. You would be able to change your filesystem structure at any time by editing your GNUstep.conf. GNUstep.conf is initially created by gnustep-make, so it makes sense to have the option there. Yes, but it doesn't need to be. It's a development tool. Things should be decoupled ... -make and -base don't really talk or depend on each other. Not entirely true. Currently -base depends on -make for configuration. Everything is driven by GNUstep.conf. You'll be able to use -base (/any other GNUstep software) without -make if you want, if you set manually everything in GNUstep.conf. That's right. Yet if -base generated GNUstep.conf then you wouldn't need to do that. You could replace -make with any other tool that could translate from the GNUmakefiles. We just need to save the configured filesystem structure in GNUstep.conf, and use it to set GNUSTEP_APPS etc. in common.make, and we're almost done (except that a few things, like GNUSTEP_INSTALLATION_DIR, will no longer work in that context). ;-) Then every application, at launch time, must set up the whole fs structure? Yes ... we're not really "almost done". :-( ... we also need to have gnustep-base load the directory structure from GNUstep.conf and use it when searching for stuff at runtime :-/ For long lived processes this might be fine but for short lived tools you're imposing a considerable startup delay. I added PLATFORM_SUPPORT as a step in avoiding that. If you said something like: GNUSTEP_INSTALLATION_DOMAIN=PLATFORM_LIBS you'd get your library installing into /usr/lib and so forth. So any GNUSTEP_* spec uses OpenStep domain layout. Any PLATFORM_* spec uses the local platform specifics. For consideration, isn't GNUSTEP_INSTALLATION_DOMAIN a little too confusing? I'd prefer something a little more like: GNUSTEP_INSTALLATION_DIR (we'd have to change some -make internals) The problem with this is that it would break backwards compatibility ;-) > There are makefiles out there that might be using it in the old meaning. We can't break those, at least not when they are used in the old context. ;-) Well, yes. Making it *ION_DIRECTORY would solve that while keeping the semantic idea. GNUSTEP_INSTALL_INTO GNUSTEP_INSTALL_DESTINATION or perhaps we should be thinking more along packaging lines... GNUSTEP_PACKAGE_LOCATION Packagers can easily add a line to their makefile or preamble this way... I don't really have an opinion, I like GNUSTEP_INSTALLATION_DOMAIN but we can change the option name, it's not a problem. :-) Comments/suggestions on the name are welcome. :-) Cool. Others? Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Private library symbols...
Hi Richard, You've made some recent changes to base with the idea of making private functions in base more obviously private and less accessible. It seems to be that there is really only one goal with these changes: applications/tools shouldn't be using private functions in base Is there any other objective that I'm missing? If this is the case, I think the approach being taken here isn't the one which we should be pursuing. The original situation is we have functions like these: NSString *GSLastError(int); BOOL GSEnvironmentFlag( const char *, BOOL ); which make these functions seem like GNUstep API additions but really they are private. What has been done is create an "artificial" object @interface _GSPrivate : NSObject + (NSString*) error; @end @interface _GSPrivate (ProcessInfo) + (BOOL) environmentFlag: (const char *)name defaultValue: (BOOL)def; @end Now I say artificial because it doesn't conform to an object design. There never is an actual instantiation, for example, so you're always sending messages to the class. There are many other things which make this not really an object. Doing this adds many more bytes to the library. It also makes these method lookups rather than function calls so they are slower. So we've added an artificial/strange object, increased the library size and slowed down those function calls all in an effort to prevent applications using our private functions. Is this right? Now its long been idomatic to use the underscore to mark private symbols. In fact, this is precisely what you've done with the class name. Further, I think this makes navigating the source harder. Quick, tell me without searching where you're going to find the implementation for the above two functions? Why don't we simply change the functions to conform to idomatic norms? NSString *_GSLastError(int); BOOL _GSEnvironmentFlag( const char *, BOOL ); and be done with it? This won't add to size. This won't slow things down. This stays in convention. If you really want, we could further decorate along the lines of: NSString *_private_GSLastError(int); BOOL _private_GSEnvironmentFlag( const char *, BOOL ); although I don't see the point of doing that. I do see some merit in making these private functions GNU convention NSString *_gs_last_error(int); BOOL _gs_environment_flag( const char *, BOOL ); as that is keeping with the style guide. Further, if the problem is, as you say, "symbol pollution" why not stop the pollution where it really is occurring: the exports symbol table? Its a linker problem, not really a source code problem. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Private library symbols...
Richard Frith-Macdonald wrote: On 16 Oct 2006, at 04:13, Sheldon Gill wrote: Hi Richard, You've made some recent changes to base with the idea of making private functions in base more obviously private and less accessible. Yes ... as obviously private as possible. It seems to be that there is really only one goal with these changes: applications/tools shouldn't be using private functions in base Is there any other objective that I'm missing? Well, that's the main tactical objective ... the strategic objective is to improve maintainability ... so centralisation and clarification internally is almost as much of a goal as simply trying to ensure that external apps/tools don't use private stuff. Okay. If this is the case, I think the approach being taken here isn't the one which we should be pursuing. The original situation is we have functions like these: NSString *GSLastError(int); BOOL GSEnvironmentFlag( const char *, BOOL ); which make these functions seem like GNUstep API additions but really they are private. What has been done is create an "artificial" object @interface _GSPrivate : NSObject + (NSString*) error; @end @interface _GSPrivate (ProcessInfo) + (BOOL) environmentFlag: (const char *)name defaultValue: (BOOL)def; @end Yes, the idea is to collect everything together as much as possible, making it easier to find these things and making it clear that the various mechanisms are used internally. Now I say artificial because it doesn't conform to an object design. There never is an actual instantiation, for example, so you're always sending messages to the class. There are many other things which make this not really an object. This is a work in progress ... I'm not sure yet whether it would be good to have an instance and use instance methods rather than just a class and use class methods. The main reason for using a class is to use language features to support encapsulation and maintainability rather than depending solely on conventions. Well, you actually are relying on conventions anyway. You've called the class _GSPrivate using the underscore convention to indicate privacy. Also, these are private function calls within the library. Encapsulation doesn't really apply here. Doing this adds many more bytes to the library. It also makes these method lookups rather than function calls so they are slower. True, but these are very minor overheads and I think clarity and maintainability come first before looking at optimisation (obviously we can optimise by caching method IMPs or by using a struct as a dispatch table rather than using a class). I'm quite aware of how we can optimise method calls but this isn't really optimisation. I also find this inconsistent with your previous statements about avoiding 'bloat', as you put it. Surely more size and less speed for no functional changes is the very essence of 'bloat'? I don't agree that these changes make anything more maintainable or easier than simply decorating the function calls with an underscore in the conventional way. So we've added an artificial/strange object, increased the library size and slowed down those function calls all in an effort to prevent applications using our private functions. Is this right? As you can tell from my answers above, it's only partially right. Now its long been idomatic to use the underscore to mark private symbols. In fact, this is precisely what you've done with the class name. Yes, I've tried to use every signal I could think of ... the leading underscore, the word 'Private' the exclusion from any external headers and reduced linker symbols, and the inclusion of comments. Further, I think this makes navigating the source harder. Quick, tell me without searching where you're going to find the implementation for the above two functions? I'm very surprised at this comment ... since a big part of the intent is to make navigating the source *easier* and I believe this is achieved. I certainly think it's not obvious where the old functions were ... but the new methods are clear since the category names tell you where the individual method implementations in each group are, the declarations are all in a single place, and you can find all the private methods implementations easily using a search for @implementation _GSPrivate. Making sure all declarations are in GSPrivate.h is good but a matter of programmer discipline and has no bearing on the function call vs class method issue. > That's a big improvement over the older code. Conventional layout has private functions near the top of the source file, just after header includes. They aren't that hard to find. Especially if you keep to convention with the underscores. Sure, the category names he
