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 snip 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. snip 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: 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] 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=23971view=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: 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 help you find where the particular function is located. I've an equivalent way which adds precisely 0 bytes to the libnrary and makes no impact on the runtime
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: 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
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: 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:
---snip here-
#!/bin/sh
# Command to make GNUstep applications
# Sets up the environment correctly and then
# invokes make.
. /usr/shared/GNUstep/Makefiles/GNUstep.sh
make $@
---snip here-
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
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: 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: 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 keyfile.ppk * Tell GNA.org about the key and wait an hour * Check ssh access plink -v -ssh -l username -i keyfile.ppk svn.gna.org * Edit Subversion configuration %USERPROFILE%\Application Data\Subversion\config [tunnels] putty = plink -ssh -l username * 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 username 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
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: 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
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: 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: 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: 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 has
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 nil 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: 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 module. Give
[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.2524tr2=1.2525r1=textr2=text
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
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]
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: 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: 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: [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
