Re: FHS compliance for libraries (was Re: gnustep-make experiment)
On Sun, 2007-01-28 at 22:37 -0800, Gregory John Casamento wrote: > All, > > Sorry to chime in so late on this one, RL has kept me quite busy over the > last few weeks. :) > > Wouldn't it be possible to change make so that it handles both setups > (i.e. FHS or GNUstep)?This way we could have one set of > GNUmakefiles to handle everything, instead of two (as Nicola > suggested). > > I believe that all of the extra setup that is necessary to use the > libraries outside of the FHS represents a "barrier to entry" to some > users as they may not feel comfortable about using a set of libraries > which requires them to make basic system level change to ld.conf. It > would be nice if there was an option to install the libraries in an > FHS compliant manner to allow them to be used by GNUstep applications > or, possibly, by other non-GNUstep programs. > > Before anyone suggests it, I believe the value of splitting > APPLICATION bundles into the FHS (the various resource dirs) is > dubious at best and this debate will be left for another time. For > now we need to focus on making Libraries FHS compliant. Libraries are certainly the biggest barrier to entry-- I see a noticeable slowdown in search path times, increased disk bandwidth usage for some times, and it affects the entire system. I've removed GNUStep from several of my workstations where it was little-used, because of this. I'd heartily enjoy seeing things moved FHSward. I'd be glad to help test, too. Aria signature.asc Description: This is a digitally signed message part ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
fswatcher inotify patch
Hi
On my system (Ubuntu), I need the following patch and additional file
for fswatcher-inotify.m to compile. sys/inotify.h doesn't exist and
linux/inotify.h does not define the syscalls.
local_inotify_syscalls.h comes from gamin.
Philippe
--
The optimist thinks that this is the best of all possible worlds, and the
pessimist knows it. J. Robert Oppenheimer
Index: fswatcher-inotify.h
===
--- fswatcher-inotify.h (révision 24428)
+++ fswatcher-inotify.h (copie de travail)
@@ -25,7 +25,10 @@
#ifndef FSWATCHER_INOTIFY_H
#define FSWATCHER_INOTIFY_H
-#include
+#include
+#include
+#include
+#include "local_inotify_syscalls.h"
#include
#include "DBKPathsTree.h"
#ifndef _LINUX_INOTIFY_SYSCALLS_H
#define _LINUX_INOTIFY_SYSCALLS_H
#include
#if defined(__i386__)
# define __NR_inotify_init 291
# define __NR_inotify_add_watch 292
# define __NR_inotify_rm_watch 293
#elif defined(__x86_64__)
# define __NR_inotify_init 253
# define __NR_inotify_add_watch 254
# define __NR_inotify_rm_watch 255
#elif defined(__alpha__)
# define __NR_inotify_init 444
# define __NR_inotify_add_watch 445
# define __NR_inotify_rm_watch 446
#elif defined(__ppc__) || defined(__powerpc__) || defined(__powerpc64__)
# define __NR_inotify_init 275
# define __NR_inotify_add_watch 276
# define __NR_inotify_rm_watch 277
#elif defined(__sparc__) || defined (__sparc64__)
# define __NR_inotify_init 151
# define __NR_inotify_add_watch 152
# define __NR_inotify_rm_watch 156
#elif defined (__ia64__)
# define __NR_inotify_init 1277
# define __NR_inotify_add_watch 1278
# define __NR_inotify_rm_watch 1279
#elif defined (__s390__) || defined (__s390x__)
# define __NR_inotify_init 284
# define __NR_inotify_add_watch 285
# define __NR_inotify_rm_watch 286
#elif defined (__arm__)
# define __NR_inotify_init 316
# define __NR_inotify_add_watch 317
# define __NR_inotify_rm_watch 318
#elif defined (__SH4__)
# define __NR_inotify_init 290
# define __NR_inotify_add_watch 291
# define __NR_inotify_rm_watch 292
#elif defined (__SH5__)
# define __NR_inotify_init 318
# define __NR_inotify_add_watch 319
# define __NR_inotify_rm_watch 320
#else
# warning "Unsupported architecture"
#endif
#if defined(__i386__) || defined(__x86_64) || defined(__alpha__) || defined(__ppc__) || defined(__sparc__) || defined(__powerpc__) || defined(__powerpc64__) || defined(__ia64__) || defined(__s390__)
static inline int inotify_init (void)
{
return syscall (__NR_inotify_init);
}
static inline int inotify_add_watch (int fd, const char *name, __u32 mask)
{
return syscall (__NR_inotify_add_watch, fd, name, mask);
}
static inline int inotify_rm_watch (int fd, __u32 wd)
{
return syscall (__NR_inotify_rm_watch, fd, wd);
}
#else
static inline int inotify_init (void)
{
return -1;
}
static inline int inotify_add_watch (int fd, const char *name, __u32 mask)
{
return -1;
}
static inline int inotify_rm_watch (int fd, __u32 wd)
{
return -1;
}
#endif
#endif /* _LINUX_INOTIFY_SYSCALLS_H */
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
Nicolas Roard schrieb: > On 1/29/07, Gregory John Casamento <[EMAIL PROTECTED]> wrote: >> All, >> >> Perhaps we could put a set of images to represent the key masks >> needed.The #/+/- scheme adds absolutely nothing and only clutters >> the interface. It would be better to implement a mechanism which >> shows some images (pehaps *original* versions of the same symbols used >> in Cocoa) to represent Control, Command, Shift, and Alt. > > Images would be better, indeed. You probably do not need to show the > shift modifier though -- simply use an uppercase letter (unless it's > not a letter, of course). > Not sure here. At least reusing the Apple images wont help those of us that don't use an Apple keybord :-) Also when displaying images we need another whole set of changes to the size calculation and drawing code in NSMenuItemCell. Who ever wants to do this is free to do so, but I wont do anything in that direction. To answer the other mails as well: - Not showing the modifier symbol for Alt wont help. What would you display for a key that works without any modifier? For example F12 could be a short cut and Alt-F12 one as well. How would a user be able to distinguish these? - Showing the full explanation of a modifier is a bubble help is in itself a great idea. But it does not resolve the original problem that we need to display something to give the user an idea, what modifiers have to be used. - The code already tries to remove the shift modifier, when an uppercase letter is given. The code here may be wrong, as I did change Nikolaus original code. Sorry, as I wrote in my first answer, I am not happy with the current approach either. But all the answers up to now suggest that nobody actually sees the problem here or is taking it serious. I am going to drop out of the further discussion until that stage has been reached. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: FHS compliance for libraries (was Re: gnustep-make experiment)
I'm a bit confused by your email. ;-) I guess it simply shows that most people are not aware of the 'radical' filesystem-independency plan that we have been working on in gnustep-make and gnustep-base for the past few years! ;-) > Wouldn't it be possible to change make so that it handles both setups (i.e. > FHS or GNUstep)? This is exactly what the current implementation is designed to achieve! :-) Nobody will have to make any changes to their GNUmakefiles, unless they have custom makefile/shell code that explicitly depends on the GNUstep-filesystem hierarchy (in that case, of course, they will have to modify it to make it more general (but the old one would keep working if you never use Linux FHS)). > This way we could have one set of GNUmakefiles to handle everything, instead > of two > (as Nicola suggested). Nobody ever suggested that you need to have different GNUmakefiles for the different filesystem hierarchies! Your GNUmakefiles will work in whatever way you have configured GNUstep; gnustep-make (and gnustep-base) will manage the local filesystem configuration in a transparent way. That has already been built in into gnustep-make and gnustep-base, by the way, only the final steps are missing. ;-) I guess the only really open discussion points are the ones raised by Matt, summarized in one of my last email -- how to avoid having to set GNUSTEP_MAKEFILES to compile, and how to easily let ./configure and shell scripts have access to various bits of gnustep configuration (eg, how do you check for the existence of a gnustep library in ./configure). Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
On 1/29/07, Nicolas Roard <[EMAIL PROTECTED]> wrote: Images would be better, indeed. You probably do not need to show the shift modifier though -- simply use an uppercase letter (unless it's not a letter, of course). And of course I don't think it's really useful to put the alt modifier as it will here all the time ? -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
On 1/29/07, Gregory John Casamento <[EMAIL PROTECTED]> wrote: All, Perhaps we could put a set of images to represent the key masks needed.The #/+/- scheme adds absolutely nothing and only clutters the interface. It would be better to implement a mechanism which shows some images (pehaps *original* versions of the same symbols used in Cocoa) to represent Control, Command, Shift, and Alt. Images would be better, indeed. You probably do not need to show the shift modifier though -- simply use an uppercase letter (unless it's not a letter, of course). -- Nicolas Roard "La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à retrancher." -- Antoine de St-Exupéry ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
