Re: gnustep-make experiment
Matt Rice wrote: On 2007-02-10 17:34:59 -0800 Nicola Pero [EMAIL PROTECTED] wrote: The only objection i've heard from gnustep.pc is Its not the way GNUstep stores information. Here is a refresher -- 1. it adds an external dependency upon which *everything* would depend an entirely optional dependency, people could continue sourcing GNUstep.sh. 2. it is slower -make is not a bottleneck... for example on my machine -make building base here takes 2 minutes 3 seconds... make when base is already built takes 2 seconds.. where adding this stuff to make would be 0.006th of a second per invocation of pkg-config/gnustep-config this argument is hogwash. 3. it is designed for something else (which adds complexity) It does exactly the same thing gnustep-config.sh does. that adds no complexity... 4. it requires rewriting and redesigning stuff with no clear advantages there are clear advantages... now I can add stuff to configure for things *using* gnustep-make which attempts to see if GNUstep libraries exist. there could be a way to bootstrap gnustep-make to just work without any gnustep specific environment variables. The objection i have with GNUstep.conf is it isolates gnustep from the rest of the world. I find that objection vague. Can you explain the practical meaning of it isolates gnustep from the rest of the world ? It's a text file in /etc/GNUstep.conf containing something like it can be set by --with-config-file when configuring make. If this is done, GNUstep can find GNUstep.conf without setting GNUSTEP_CONFIG_FILE... GNUSTEP_CONFIG_FILE is provided to override the location of /etc/GNUstep.conf if you didn't change the default GNUstep.conf location. I refuse to rely on a feature which a) 99% of the time is fine. b) the 1% of the time works unless your relying on GNUstep.conf being findable theres no way to reliably locate it if the caller was not generated by GNUstep-make's configure script. That's a chicken and egg problem with every configuration. If I compile apache in /opt the configuration of apache will live in /opt/etc/apache, or /opt/etc/httpd, which is not the system default location. Because I choose it to be different, hence the need for a configure option to point to the config file. The same goes for the .pc files. Ever tried to build the pkg-package supported libraries in non-default places (like in /usr/GNUstep/System/Library/Libraries)... then you also have to set the PKG_CONFIG_PATH variable to make make it all happen. Same goes for ldconfig... it per default only searches the FHS default places. Hence the need for /etc/ld.so.conf... but what if you configure ldconfig for /usr/GNUstep/System/Configuration as the /etc directory. What I am trying to say is that every system that you invent to do automagic for paths, libraries etc. will rely on defaults and needs environment vars for the exceptions. I doubt you will ever find a package that solves all problems. Just my 2 cents. Dennis ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Adam Fedor wrote: On Feb 11, 2007, at 3:30 PM, Alex Perez wrote: there are clear advantages... now I can add stuff to configure for things *using* gnustep-make which attempts to see if GNUstep libraries exist. there could be a way to bootstrap gnustep-make to just work without any gnustep specific environment variables. Those are not advantages of pkg-config. Those are examples of where the use of pkg-config would provide the same functionality. Early on in this thread Nicola suggested both gnustep-config.sh and the use of a makefile fragment as ways of doing the same thing, so pkg-config provides no advantage in this respect. They advantages in that many other people already know how the hell they work, and pretty much any newcomer does NOT know how this other funky system we invented works; even if it's very simple, this RAISES the barrier to entry. It does not lower it. This is why the whole dependency argument isn't as critical as some of us seem to believe it is. That is not an advantage in this case. pkg-config main reason for being is to help find compile and link flags for linking in other libraries. It can be extended, which Matt has suggested in this case. But the extension here is just to FIND the GNUstep makefiles - and now we are just back were we started - the newcomer still has to learn how to use our 'funky' makefile system. The thing that various people have been arguing about here is, 'how do we find out various bits of meta-data about the GNUstep system?'. pkg-config is woefully inadequate for this work and doesn't even come close to covering other requirements of the make system, like compiling and linking in bundles, frameworks, palettes, etc. The only way to work around the fact that we somehow have to find The GNUstep Environment is by having a script in a file system compliant place that returns what is needed. So on a Unix system place gnustep-config.sh in /usr/local/bin or /usr/bin and on Windows in /Windows/Programs (?)... etc. Dennis ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep-make experiment
Just to chime in... I compiled pkg-config from source a couple of times and it does need glib. I haven't been able to work around glib. Dennis Wim Oudshoorn wrote: Matt Rice [EMAIL PROTECTED] writes: On 2007-02-09 09:18:02 -0800 Wim Oudshoorn [EMAIL PROTECTED] wrote: So next I tried to download pkg-config version 0.21 and compile it (on MS Windows). Of course that failed because I hadn't installed glib. So I gave up. (I tried once to get glib compiled on windows and it wasn't a pleasant experience.) It does not require anything but a reasonably well working C compiler and a C library, but can use an installed glib if that is present. Well, did you actually try compiling pkg-config? I did not investigate deeply but the suggested way of compiling: ./configure make Did not work. ./configure succeeded splendidly, but make failed and the reason was that glib.h could not be found. But I don't want to start a discussion in the GNUstep mailing lists on how to install pkg-config. I just wanted to see how it would work on windows. Wim Oudshoorn. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUSTEP_INSTALLATION_DOMAIN
Hi Nicola, 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] 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] I understand the use of domains, since it abstracts the filesystem from the user, but there is no NETWORK equivalent for FHS and WINDOWS, and some systems like to use /opt, which you rule out. And what does SYSTEM mean on a Unix but non-FHS system, does that mean /usr or /, or /opt? Just my 2 cents. Dennis Leeuw Nicola Pero wrote: I'd like to propose a new option for gnustep-make ... GNUSTEP_INSTALLATION_DOMAIN which could take the values SYSTEM / LOCAL / NETWORK / USER. This option can only be set on the command line, or before including common.make ... but using it in GNUmakefiles should be discouraged as all packages should install by default in the default locations ... except for maybe gnustep-base :-) The meaning of the option is obvious ... it would determine if we install into System/Local/Network/User (currently you use GNUSTEP_INSTALLATION_DIR for this). The advantage of this option is that it could work with the Unix (or generally 'native') filesystem support ... eg, on GNU/Linux, make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM would install stuff in /usr, while make GNUSTEP_INSTALLATION_DOMAIN=LOCAL would install stuff in /usr/local. We'd still keep GNUSTEP_INSTALLATION_DIR, but only in the situations that used to work (ie, GNUstep or Apple filesystem layout), and it would be discouraged to set GNUSTEP_INSTALLATION_DIR inside GNUmakefiles themselves. In general, GNUSTEP_INSTALLATION_DIR doesn't work well with the more flexible directory layout. Most of the times you want to set GNUSTEP_INSTALLATION_DIR to GNUSTEP_SYSTEM_ROOT, for example, but that variable is no longer defined until later inside the GNUmakefiles (you're no longer supposed to have sourced GNUstep.sh!), and moreover, it might not even have much sense if the filesystem is not the GNUstep one. GNUSTEP_INSTALLATION_DOMAIN would let you do the same things, but could be made to work in more general contexts. :-) Comments welcome Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Fwd: Versioning/release policy proposal
Hi Richard, A clear document, the only thing I miss is a rationale for the use of the SONAME with a major.minor structure, instead of the more common major. I think this would help in the understanding why, and resulting in less discussion. I could even imagine that you use the SONAME major for make and base, while keeping major.minor SONAME for gui/back unit they hit 1.0. Just an idea. Thanks, Dennis Richard Frith-Macdonald wrote: Not sure this got through ... so resending Begin forwarded message: From: Richard Frith-Macdonald Date: 5 October 2006 11:28:37 BDT To: Adam Fedor [EMAIL PROTECTED], Gregory John Casamento [EMAIL PROTECTED], Nicola Pero [EMAIL PROTECTED] Cc: Developer GNUstep gnustep-dev@gnu.org Subject: Versioning/release policy proposal This is a proposal for conventions to be adopted for releasing GNUstep packages ... the idea being that something like this could be added to our FAQ and used as a reference for making releases and to some extent guiding what changes we allow into trunk in SVN. I'm CC'ing this to the developer list for information purposes, but I lack the time to respond to comments directly (especially if this gets a lot of flaming etc) other than those from GNUstap maintainers. I'm aware that not everyone can be pleased. but I've made my best attempt to satisfy people, and I'm hoping that Adam, Gregory and Nicola will broadly agree and add any final polish taking any other opinions into account. 1. Release Version Numbering scheme We retain the current major.minor.subminor version numbering scheme for releases and for naming tags in svn. eg. when making a release of version 1.2.3 of package foo the svn tag is foo_1_2_3. This is clear, conventional, and well understood. 2. Library Version Numbering scheme We retain the current link between release versions and library (SONAME) versions ... in that changing the major or minor version number of a release also implies changing the library version number, but changing the subminor number does not. So release 1.2.3 of package foo implies library libfoo.so.1.2 as does release 1.2.4 etc. This provides a clear and simple link between release version and library version while allowing us to make releases without having to change the library version we expect apps to link to. 3. Policy on changing version numbers We change the minor version number (and therefore the library version) when we break backward compatibility . This will mean that most releases we make will only change the subminor number rather than the minor number even where we have added substantial new features. While I realise that this has a problem with public perception being that the project is dead because it never makes 'big' new releases, I think it's better to address the problem with improved publicity of what's in the new release rather than by hoping that a big version number change will do it for us. On the rare occasion where we want a big public change, we would change the major version number (and of course SONAME). 4. Release stability policy We advertise a 'stable' release *every* time we break backward compatibility. Doing this requires making two releases pretty much at the same time and bumping the minor version number for each. Eg. if the last release was 1.3.24 then we release 1.4.0 as 'stable' and 1.5.0 as 'unstable', each with the appropriate change in the SONAME. All releases (if any) in the 1.4 family would be bugfix releases. I suspect the vast majority of people would just use the 'unstable' releases (largely defeating the point of having 'stable' ones), but the overhead of doing a 'stable' release is very low, so I don't see why we shouldn't do it. We can make 'stable' releases be those with even subminor version numbers. 5. Standard release procedure (backward compatible with previous version) a. tag the version for release using the name_major_minor_subminor convention. b. make tarballs and installation packages c. bump the subminor version number in trunk d. put release on ftp site and publicise 5. Standard release procedure (NOT backward compatible with previous version) a. bump the minor version number and SONAME and reset the subminor number to zero b. tag the version for release as 'stable' using the name_major_minor_subminor convention. c. make tarballs and installation packages d. bump the minor version number and SONAME and reset the subminor number to zero e. tag the version for release as 'unstable' using the name_major_minor_subminor convention. f. put releases on ftp site and publicise 6. Bugfix release procedure a. if this is the first bugfix release of a package version, make a branch from the tagged release using the tag name as the branch name eg. if the release was tagged in svn as foo/tags/foo_1_2_0 then the branch is foo/branches/foo_1_2_0 b. apply bugfixes to the branch c. tag
Re: gnustep release numbers
To quote my own documentation at http://ocean.made-it.com/Documents/Library.html The so-name versioning system is described almost everywhere as: quote Versioning convention says we have three release numbers: 1. major release number 2. minor release number 3. micro release number Micro release changes may: improve performance, scalability or some other qualitative property, or fix a bug that does not change the API nor the ABI. Which means no application built against the old version should stop functioning with the new version, but also the otherway around: applications built against the new version should work with the old library. No functionality can be added to a micro release change. Minor release number changes should be ABI comptible, but can enhance functionality. This means that applications built against the old API will work, but applications built against the new API might not work with the old ABI (hence they depend on the new minor number). Major release changes will break ABI and API compatibility and thus require a complete rebuild of everything that depends on the libraries. /quote And as far as I can tell this is exactly why is being done with the GNUstep versioning system. This of course has nothing to do with stable and unstable releases. SVN and the daily snapshots are the unstable releases, and the numbered releases are stable ones. Currently the frequency in which we jump Major release numbers, and thus breaking the ABI are not frequent. Minor releases is open for discussion, depending on your definition of frequent. And Micro should be frequent. The discussion is about the Minor part, so let's concentrate on that one. For a maintainer the choices are quite simple, IMO: 1) There is an app that needs the additional functionality, so you have to accept to also supply a library upgrade. Nothing more, so no other applications need to be upgraded. 2) No app needs the additional functionality... you do not have to do anything Am I missing a point here? With kind regards, Dennis Leeuw Helge Hess wrote: On Oct 5, 2006, at 07:31, Richard Frith-Macdonald wrote: If I seem incredibly slow in understanding what you mean by 'stable', Sorry, seems I can't really explain stuff in a compatible way? ;-) Well, its actually not my understanding of stable but the requirements enforced by soname versioning? I'm actually not sure why there is a discussion on what a stable ABI / soname is because its clearly defined and documented. Its also kind of obvious that you are not supposed to have 10 different soname versions on a working system but just two or three :-) please understand that it's just that the idea of trying to enforce a frozen ABI for years seems utterly impractical. Why? Its basically just that a) we tag one branch as, say GNUstep 1.2.0, the stable one. we announce this on the website and maintain soname stability requirements b) development continues as-is in trunk with alpha releases (GS 1.3). In fact you can do many more releases because you are not expected to maintain sonames. BTW: please stop exaggerating ;-) I said 2 years not for years and also at least 1 year :-) Thats about the devcycle of Linux distries for endusers. It also doesn't need to be completely fixed on a time. Eg if we have a *major* leap in functionality (say KVO is implemented in base or Windows support gets perfect or so), we can do a new stable release. But I don't expect this to happen a lot :-) Development is more the incremental way. I suppose a 12 month cycle should be reasonable, we would need to see whether we really have enough new features after 12 months :-) The thing which is utterly impractical is requiring thousands of users to update every few months and having to preserve ten binary releases on the system because they might want to install an old tool/ daemon. Even for gnustep-base it would not be easy (the drive to MacOS-X compatibility is too strong), I completely disagree. If we tag gnustep-base 1.2.0 as stable and this doesn't include, say NSOutputStream. Now I decide for OGo that we will use this class because its in OSX and its neat and whatever. What you do in this case is a backport, that is you take the class out of trunk, refit it to the stable version and include _just that class_ in your application. That happens all the day with Linux distris. If something is important to have, you get backports for stable distries. Of course one has to decide whether a backport is worth the effort (do I really want to use NSOutputStream if its not in gnustep stable? how difficult is it to refit the new class to the old base?). But its always less effort than upgrading the _very basis_ for a deployment of out-of-the-house developers. Having a few stops very likely improves the quality in various other areas as well. Eg you finally have _one_ version
Re: Checking breakage of backward compatibility
Richard Frith-Macdonald wrote: On 4 Oct 2006, at 12:46, David Ayers wrote: I'm almost indifferent on the subject. But in practice I believe people will unknowingly break binary compatibility and forget to bump the SO name. I think this is worse than forcing folks to recompile apps just because the SO name bumped even though it didn't break binary compatibility but like I said. I wouldn't mind either way. That worries me too ... but I think we *must* try to be strict about it. Is there any way we could devise an automated test for binary compatibility breakage? I once tried that... but the problem is you can only do that for the installed libraries. Is there a way I can ask a program to reveal what it needs? I only found tools that said what a lib supplies. Greetings, Dennis ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: gnustep release numbers
Yep you are right... hadn't looked at the soname naming. I expected the a soname Major, not Major.Minor. Maybe that should be the real discussion then if this naming convention is still appropriate? Dennis Helge Hess wrote: On Oct 5, 2006, at 16:01, Dennis Leeuw wrote: Currently the frequency in which we jump Major release numbers, and thus breaking the ABI are not frequent. Thats incorrect. For GNUstep the soname is Major.Minor, not Major. Which is correct because the soname compatibility indeed broke for every major.minor release in the past (classes or methods got added/ removed/behaviour changed). --- lrwxrwxrwx 1 root root 23 Oct 4 11:58 libgnustep-base.so - libgnustep-base.so.1.13 lrwxrwxrwx 1 root root 25 Oct 4 11:58 libgnustep-base.so.1.13 - libgnustep-base.so.1.13.0 -rwxr-xr-x 1 root root 7721941 Oct 4 11:58 libgnustep-base.so.1.13.0 --- You can't expect an application developed against 1.13.0 to run with base 1.10 (despite having the same major version). I think its rather trivial to proove that. Again, you can easily check for (required!) soname increases in the ChangeLog: http://www.gnustep.org/resources/documentation/Developer/Base/ ReleaseNotes/ReleaseNotes.html eg: ---snip--- Version 1.13.0 Several sets of classes have been added for dealing with urls and predicates Version 1.12.0 NSStream, NSIndexPath New classes added to the library. Version 1.10.1 NSXMLParser class added Version 1.9.2: NSError New MacOSX compatibility class ---snap--- etc. just extracted one example. per version and just included 4 versions. Base is a highly moving target for any developer. He can't know what he will be able to use on a deployed system (eg is NSStream available or not). Am I missing a point here? Yes, see above ;-) Greets, Helge ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: make help
Adrian Robert wrote: On 2006-09-27 23:04:07 -0400 Nicola Pero [EMAIL PROTECTED] wrote: This could be an interesting idea, but the main problem is that someone looking for help probably wouldn't know that to get help you need to use 'make help=yes'. Maybe whenever you type 'make' we could always print a line saying 'Please type 'make help=yes' for help' ... I like this one. In fact, you could have a msg like this: GNUstep make (version x.xx); please type make help=yes for help. That would serve 3 purposes -- tell invoker that GNUstep make is being used (in case they care), the version, and how to get help. Reading the make manual, it specifies for installed stripped versions: make install-strip, from this I find it more logical to use: install-strip install-nodebug and going on in the same logic: print-help # prints complete help print-targets # prints only the available targets print-options # prints the available options print-version # Source version print-gnustep-make-version # GNUstep-make version print-gnustep-base-version etc... Just my 2 cents. Dennis ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Advertisement for gnustep
Chris Vetter wrote: On 2006-09-12 13:38:40 +0200 Gürkan Sengün [EMAIL PROTECTED] wrote: Indeed, especially if it looks like something I am used to, say NeXTSTEP/OPENSTEP, Windows or Mac OS X. Please pretty please, don't make new themes, new looks, another we are gnome, we are cool, we are KDE, we are new, whatever new thing that is just ugly. You're absolutely right, however that is one of the major drawbacks for GNUstep -- that it DOESN'T look like KDE, GNOME or XFCE. Or should I say doesn't try to imitate Windows ??? Most people are USED to the Windows look and feel, they are NOT used (anymore) to the look of NeXT (or OSX for that matter). Maybe we should win on brains/quality instead of looks... http://today.reuters.com/news/articlenews.aspx?type=inDepthNewsstoryID=2006-08-30T130311Z_01_PEK290182_RTRUKOC_0_US-CHINA-SURGERY.xml http://marshallbrain.com/discard3.htm http://www.washingtonpost.com/wp-dyn/articles/A64857-2004May28.html ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Advertisement for gnustep
Adam Fedor wrote: On Sep 9, 2006, at 11:49 PM, Gregory John Casamento wrote: Adam, Is it an ad for new developers or an ad urging end-users to try GNUstep? It's more of an add to get more help, but I think getting more users would provide the same benefit. Maybe the best way to promote the GNUstep project is to set goals. Create an overview of the current state and the milestones. Give developers triggers where they can make contributions and what is in it for them. We all know GNUstep can be the best desktop environment around and we can beat everything that was (maybe even that will be). The trick is to get people in. So tell honestly what is missing, where they can make their hands dirty (cairo integration springs to mind). Just my 2 cents. Dennis ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: libgnustep-base split proposal
Chris Vetter wrote: On 2006-02-26 03:12:10 +0100 Alex Perez [EMAIL PROTECTED] wrote: Hear, Hear! This should be the default location. The other gnustep junk can still live in /usr/gnustep or wherever else, but the libs should be in *STANDARD FHS LOCATIONS*. Uhm ... 'scuse me, this is all good and stuff, BUT... ... NOT everyone is using GNUstep on a system that adheres to a _LINUX_ specific standard. Bash me, if you want, I just checked the FHS' web site, and as far as I can see, the only system this so called standard is targeting is Linux. Or rather the other way around, Linux is the only system 'using' the FHS. So calling the FHS a standard is a bit over the top. Maybe using pkg-config would solve this... although I do not know how portable pkg-config is to other platforms... Dennis -- It is not necessary to change. After all, survival is not mandatory. Dr. W. Edwards Deming ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: SystemPreferences
Hi Matt,
Matt Rice wrote:
Hi Dennis,
not sure if this is similar to what Chris had in mind
though i'll throw in my opinions
I would say /{System,Local}/Library/AppName/
though it is probably better suited to the
ApplicationSupport/AppName given the current file
system layout
(though IMHO Library/ is what ApplicationSupport/ and
the stuff in Library/ currently should be in
Library/GNUstep or something for local root and just
Library/ for system root possibly, this is a whole
other conversation though)
I am not so much in favour of an ApplicationSupport directory. I do not
understand it from a design point of view. If you want a design where a
folder is the application you should put as much as possible within that
folder. Not starting to re-invent the /usr/share directory... more below :)
the problem with Library/Bundles is its a catch all
which contains a bunch of completely unrelated things
Yep, but we are talking (I think) about two things. Bundles that are
shared amongst applications and Bundles only related to one single App.
The ones that belong to one single app I comment on below, the ones that
are shared are a different story. To make a little comparison. You do
not also create a Libraries/Images dir for libs that do image handling
and Libraries/Sounds for sound related libs. They are all placed within
the same dir.
i've forever been in favor of removing Bundles/
altogether though probably not vocal about it
so no not /System/Library/Inspectors
/System/Library/Foo/Inspectors/
/System/Library/Bar/Inspectors/
But then why shouldn't it be just part of the Resources dir like:
Foo.app/Resources/Library/Bundles
You keep the what is it logic, but if the thing is only used by the
application it is stored with(in) the application.
Which imho makes more sense.
so each app would be in charge of its own heirarchy in
the Library dir and not dependent the correct
Library/SomeTypeOfBundle existing
though again IMHO this should be relegated to third
party stuff, and stuff which is required/default
mostly belong in the app's resources itself to allow
for the mythical cp -r/drag and drop installation
otherwise if we have something like
/System/Library/Applications/Foo.app
/System/Library/Bundles/SomeFoo.bundle
/System/Library/Bundles/FooExample.bundle
/System/Library/Documentation/Foo/
we just have a normal unix heirarchy with a bunch of
capital letters and stuff, (things from the same
components split into many places)
where we're kindof going for
Foo.app
Foo.app/Resources/SomeFoo.bundle
and copy Foo.app to Library/Applications
Foo/FooExample.bundle
Foo/Documentation/
and optionally Foo/ to Library/
or something
To complete it it would imho even be better to have
Foo.app/Resources/Library/Documentation
Foo.app/Resources/Library/Bundles/
Thus keeping the Bundles dir, only on another level. The Bundles dir
shows a what kind of component is this from a system/programmers point
of view. Because the user should be kept unknowing of how a system
works. She should never enter the Foo.app dir. Everything within that
directory is only relevant for the developer(s), so on that level it is
important to know what we are talking about, Libraries, Frameworks or
Bundles.
I think that everything that is not shared amongst other applications
and is only relevant for a single app, should belong in the App
Resources dir.
I think the idea is to have a toplevel structure where you find Tools,
Applications and Library. Where Library contains the shared resources.
If something is not a shared resource it should be placed in the
Foo.app/Resources dir in which the toplevel structure is shown again, like
Foo.app/Resources/Tools
Foo.app/Resources/Library
Foo.app/Resources/Applications
Although Applications is most unlikely, I can imagine that the Tools dir
is there (something like the libexec directory).
Another way is to regard Resources equal to Library, but that would
break the overall logic.
From a users/developers point of view (what do I expect when I have
never seen the system before and how do I get quickly familiar with the
system) the holy three Applications, Library, Tools should appear
everywhere imho.
Greetings,
Dennis
--- Dennis Leeuw [EMAIL PROTECTED] wrote:
Hi Chris,
Would this also mean the we need a
/System/Library/Inspectors
/System/Library/Finder
/System/Library/TextConverters
/System/Library/GSPrinting just no name a view
others that are falling
in the same category.
Or am I somehow missing the point here?
Chris Vetter wrote:
Hi,
just a thought, but wouldn't it make sense to
store SystemPreference
modules somewhere else instead of
/System/Library/Bundles/ like
/System/Library/Preferences/ or sth similar?
I know, technically, they ARE bundles, but then
again, logically they
are system preferences and IMHO should be set
aside from regular bundles
that are loaded during
application/backend
Re: SystemPreferences
Hi Chris, Would this also mean the we need a /System/Library/Inspectors /System/Library/Finder /System/Library/TextConverters /System/Library/GSPrinting just no name a view others that are falling in the same category. Or am I somehow missing the point here? Thanks, Dennis Chris Vetter wrote: Hi, just a thought, but wouldn't it make sense to store SystemPreference modules somewhere else instead of /System/Library/Bundles/ like /System/Library/Preferences/ or sth similar? I know, technically, they ARE bundles, but then again, logically they are system preferences and IMHO should be set aside from regular bundles that are loaded during application/backend/whatever startup. Makes sense? -- It is not necessary to change. After all, survival is not mandatory. Dr. W. Edwards Deming ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Possible future Gorm name change
GNUstep ain't Cocoa/OSX. I don't see a point in mimicking too many of Apple's ideas. What will be next? Use gSomething (gChat) analogous to iSomething (iChat) ??? troll Wauw... cool! Nice Idea /troll ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Gorm 1.0 on GNUstep site
Scott Stevenson wrote: On Nov 2, 2005, at 5:13 AM, Stefan Urbanek wrote: Something like here: http://www.mozilla.org/products/firefox/ or here: http://www.openoffice.org/ or here: Advertisment of art.gnome: http://www.gnome.org/ Or like this? :) http://treehouseideas.com/downloads/gnustep.page Wow! This is great! I am completly amazed... If this was a competition I vote for this one. Dennis I'll see if I can find some time to templatize this weekend, but deploying it is probably somewhat depedent on having server side includes or something implemented across the site. - Scott ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Why Unanimous Consent Doesn't Work (Was: Re: why do we need change?)
Richard Frith-Macdonald wrote: On 2005-10-26 08:49:52 +0100 Dennis Leeuw [EMAIL PROTECTED] wrote: Sašo Kiselkov wrote: Alright, let's stop arguing (which doesn't lead anywhere) and starting holes in the air, but let's instead start some heavy-weight brain-storming for ideas on how to implement the problems at hand. From the dicussions before we already know that: - GNUstep needs somewhat tighter management of it's further development - GNUstep needs to better react to proposals coming from it's users (meaning people using GNUstep, not just end-users) My proposal for the first point is setting up some sort of GNUstep Steering Commitee composed of a bunch of people which would choose the direction. Perhaps 3, 4, or 5 people, the precise number doesn't matter. It should be core-developers, people who have authority, knowledge and wisdom. As for the second point, I propose setting up a discussion forum (something like a phpBB or something simmilar) entitled like GNUstep Future. In the forum there could be sections like: Could we for now, just make it a little easier (Although I like your idea). Could we first define and set (e.g. in the wiki or on the progress page). The things we think needs to be done to get GUI and Back to 1.0? I think it is a clear goal. Something we can all agree on, I don't think there isn't anybody who doesn't want GNUstep to become 1.0. We just need a list of things to be done and a timeframe. Can I support this ... Yes, a new release would be good ... I don't think anybody disagrees and I don't think anybody wants to insist on exact OpenStep compliance. Yes, we want to keep things simple. Not sure wiki is best for tasks ... how about defining tasks in the GNUstep project task manager? We (well, Adam) could set up a new task category for 1.0 release. That would be cool. Is that related to the progress page? Since that last update of the progress bar is from 2004/03/03 which is rather old. Thanks, Dennis Leeuw ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
Hi Richard, Richard Frith-Macdonald wrote: On 2005-10-26 08:49:52 +0100 Dennis Leeuw [EMAIL PROTECTED] wrote: I think it is a clear goal. Something we can all agree on, I don't think there isn't anybody who doesn't want GNUstep to become 1.0. We just need a list of things to be done and a timeframe. Personally I see three, largely independent targets that I think, we should be aiming for ... Target one: As already identified, gui/back reliability/polish/10.0-release ... proibably the most important target ... The two gui/back issues that really annoy me are ... 1. window manager interaction ... I want clicking on windows to work *reliably*, so that when I click on any GNUstep window a. The application activates (shows its menu and panels, and raises the window clicked on). b. The clicked winbdow starts accepting keyboard input c. any other GNUstep application deactivates (hides its menu and panels) 2. popup/pulldown menu operation ... sometimes (often) popup menus seem to fail to track the mouse, so you can't select their buttons. These points seem to me are THE goals for a 1.0 release. My question is about the next one. How much I would want to have Camaelon integrated I think it would be wise to move it to e.g. 1.1. What do you think? And the one new development I'd really like to see is ... Camaelon integration into the gui. I have no particular need for it myself, but it's a good selling point and it's needed for my third main target. Cut the app part. Just to stay on the (changed) subject Target three: ms-windows support ... we've made a lot of progress on this, but we *should* be taking it a lot further. Personally I want to run GNUstep on windows (when I have to use windows) and have it look/feel like GNUstep/NeXTstep. However, a lot of people want it to look/feel like windows, so we need to have a windows theme (and Camaeleon built into the gui as I mentioned above). We need windows backend/gui development work, and we need to be able to support both windows and OpenStep style inter-application communications (cut/paste, DnD, services, notifications, workspace/session management etc), though this isn't going to happen quickly and must be viewed as a long term goal. Here my question is also, is Windows a 1.0 goal or should it be post-1.0? Of course, there are many other things we want to do, but even concentrating on three main targets is a LOT of work, and I don't think having more than three formal goals is a good idea. I think you are very right. We have to take little steps at a time. Thank you so much for this input. I think a task list is now emerging for a clear defined goal. Let's here some more input! With kind regards, Dennis Leeuw ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: why do we need change?
Hi Gregory, To get to 1.0 I think a roadmap is needed. Looking at: http://savannah.gnu.org/task/?group_id=99 Maybe someone should define which one of those tasks needs to be completed before GNUstep can be 1.0. And those points should be made more visible on the website, as to get peoples attention. All other stuff should be done in a post 1.0 branch or even not excepted, until after the 1.0 release. I believe that first and foremost we need to stop tying ourselves to the OpenStep specification. Yes, it is a good guideline, but I don't think we should use it as a measure for the 1.0 anymore. Some of the AppKit classes in it are not used any longer and thus we really shouldn't see these as showstoppers for the 1.0. We need to come up with a list of things which should be accomplished prior to the 1.0 release of GNUStep-gui. Once this is done, we should announce GNUstep 1.0 to the world. I agree with you that the OpenStep spec should not be leading anymore. I think GNUstep already has out grown the spec. It should now stand on its own feet, with own ideas and an its own direction. But before that can be accomplished we need to show the world we are ready to do that. And I think a 1.0 release would be a good marker. After that we have to think about the future for 2.0 and maintain 1.0. But who is going to take the lead to create a list of things to be done before we can claim 1.0. And a bigger hurdle for the GNUstep community how are we going to agree on it. Many of those discussions tend to go no where on the GNUstep lists. I suggest that one person (or a very small group) decides what needs to be done and setup a rough timeframe in which they would like it to be accomplished. If the timeframe conflicts with reality (no body wanting to pick up a certain part), then the idea of Adam for a bounty for that subject can be used. In my opinion everything should now be aimed at getting at 1.0. With kind regards, Dennis Leeuw ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
