Re: Crash with new-style exceptions on FreeBSD amd64
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Helge Hess wrote: > On Mar 14, 2007, at 21:46, Michael Gardner wrote: >> I'm having problems using "new-style" exceptions with GNUstep on >> FreeBSD 6.2 (amd64). > > Does GNUstep support @throw, @catch?? > > Thanks, > Helge Yes, for almost two years now. - -- Saso -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+H6YakxhuWWzY78RA59BAJ4nxCTL5SAwlwWATf/6sgUTicVpbQCcDPG6 z0kQUjyb9Ca0tTbDL4iBOmo= =uYWJ -END PGP SIGNATURE- ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Project Center status, or lack thereof...
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I would love to see more work being done on PM (either by me, or others), since I haven't had much motivation lately (nobody used it, at least not that I would know...). Integration into the GNUstep project itself is a problematic issue. I have no problem releasing all code for it under GNU GPL 2 - make no mistake, I love free software and the ideas behind it and I support them. However, recent FSF work on GPL 3 has raised my eyebrows quite often. BSD licenses, on the other hand, appear to me to be a bit too liberal. I just don't see the reason for a copyright assignment, when the same effect can be achieved with a proper free software license (GNU GPL 2), which makes sure that free software stays free. Anyways, I don't want this discussion to turn over into an overly bloated law-oriented flamewar of licenses and copyrights. If we agree that PM in GNUstep is a good thing *based on technical merits* and a copyright assignment is required to do so, I would probably sign it. I think the free software world is lately spending too much time talking about law and too little about code. And besides - in my country the law states that I cannot hand down my copyrights to anything I create :-) I can grant anybody I want the same rights, but my own rights 'stick' forever onto me :-P - -- Saso Gregory John Casamento wrote: > I believe that this is worth looking into at this point. > > -- > Gregory Casamento > > - Original Message > From: Yen-Ju Chen <[EMAIL PROTECTED]> > To: Gregory John Casamento <[EMAIL PROTECTED]> > Cc: GNUstep Developers > Sent: Sunday, July 8, 2007 1:03:21 PM > Subject: Re: Project Center status, or lack thereof... > > On 7/7/07, Gregory John Casamento <[EMAIL PROTECTED]> wrote: >> All, >> >> I would like to get this fixed at some point. PC is one of our core >> applications and it should work with the latest release, but yet it's not >> gnustep-make 2.0 compliant which, basically, renders it useless. See this >> comment: >> >> "As can be seen, I did not create a ProjectCenter packages because the >> current release ( >> 0.4.3) does not work with make 2.0! I do request that a new version be >> release to conform to the current make release." >> >> I've been thinking lately about plans to integrate Gorm and ProjectCenter... >> to have better communication between them.I would prefer to have someone >> to work with on this instead of doing it all myself as my work load for my >> company has increased dramatically lately (yes... running a consulting >> company takes time and effort). >> >> My sincerest apologies to Serge, but I would appreciate it if anyone who is >> interested in maintaining PC would let me know. > > Maybe it is worth to merge ProjectManager (http://home.gna.org/pmanager/) > which seems to have better text editing (syntax highlight, rulers). > Copyright assignment from Sašo is probably needed. > > Yen-Ju > >> Thanks, GJC >> -- >> Gregory Casamento >> >> >> >> >> ___ >> 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 > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGkWDEakxhuWWzY78RA/SkAJ9xst3Ep/FS7gzUCeFp4shLX4R8aQCffbYR p1bkqjnYuxJ3rPqIA06GgsM= =I6o0 -END PGP SIGNATURE- ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSThread limits?
The problem you're experiencing is because GNUstep's runtime creates
threads with a detach state of PTHREAD_CREATE_JOINABLE, which don't
release the resources associated with the thread until another thread
calls a pthread_join() on the terminated thread in order to collect its
return status. Which is kind of a bug in GNUstep, because you have no
way of joining it manually.
Your best bet is creating the thread manually, not using the NSThread
API. I use the following code snippet to do the trick:
pthread_t thread;
pthread_attr_t attrs;
if ((code = pthread_attr_init (&attrs)))
{
// Error initializing thread attributes
}
if ((code = pthread_attr_setdetachstate (&attrs, PTHREAD_CREATE_DETACHED)))
{
// Error setting thread attributes
}
if ((code = pthread_create (&thread, &attrs, ThreadFuncCallback, NULL)))
{
// Error creating thread
}
This has worked for me with thousands of threads being created and
terminated.
--
Saso
Marc Wan wrote:
> hello!
>
> I am looking to create a server that maintains a pool of a few
> hundred threads at a time, and being a fan of objective-c, i had hoped
> to be able to use GNUStep to do this on non-mac platforms.
>
> unfortunately, I don't seem to be able to fork more than about
> 150-160 threads using
> NSThread::detachNewThreadSelector:toTarget:withObject. on my macs
> here, i can easily do 1000 (i didn't test higher).
>
> after this on Linux, I get:
>
> : Uncaught exception NSInternalInconsistencyException, reason: Unable
> to detach thread (unknown error)
>
>
> i had worried that this was a linux (ubuntu 6.10 LTS Server) issue,
> but /proc/sys/kernel/thread-max says that it'll handle over 143000
> threads ... some casual browsing of NSThread.m didn't immediately show
> any limitations.
>
> any idea why this might be happening?
>
> thanks,
> mark.
>
>
> ___
> 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: @property coding style
On 01/29/2012 12:56 PM, David Chisnall wrote: > On 29 Jan 2012, at 07:51, Richard Frith-Macdonald wrote: > >> But I do still recommend ASSIGN, ASSIGNCOPY, and to a lesser extent, >> DESTROY. As these make it easier to reliably/safely manage reference >> counting. > > I forgot about those - I don't think of them as GNUstep extensions, since I > have implementations of them in another header so that I can use them on OS X > too - and I totally agree with Richard. Using these makes life a lot easier, > and avoids a lot of simple errors. Agreed, I'd be totally lost without those in my code. It has become such a strong habit, that using '=' to assign object pointers gives me a rather unpleasant feeling in my stomach. -- Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Why does StepTalk not see my class?
StepTalk somehow doesn't seem to see my implementation of the NSExpression class which I compiled into libgnustep-base. The library which it is linked with is correct (the one _with_ the NSExpression implementation). Do I need to recompile StepTalk too? Or do I need to implement some special thing inside StepTalk for it to understand how to communicate with NSExpression? Regards Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep support for Core Data?
Quoting Quentin Mathé <[EMAIL PROTECTED]>: > Hi Saso, > > I'm very happy to hear that. I just want to let you know I have > implemented NSExpression, NSPredicate, NSCompoundPredicate and > NSComparisonPredicate except raw predicates parsing support related > to -initWithFormat: method. I worked on it one month ago, but I was > away from home at this time and I forgot the hard disk where I stored > this stuff when I came back; however I should be able to recover this > hard disk in one or two weeks. > That's great news! So I'm back off to CoreData. Please try to publish the implementation ASAP so the entire thing can move on. Until then, I'll implement the parts of CoreData that are not directly connected to predicates or KVO (are there any? ^_^; ). > For KVO, Gregory Casamento was planning to work on it, he talked > about it on gnustep-dev list. > That's also great. :-) > > May be I or somebody else can help you� > I'm looking myself to getting Tiger for Intel so that I can test and compare most of the stuff immediately. But until then, your help will really be in need. > > Very cool. > *fingers crossed* Thanks Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Why isn't GNUstep built as frameworks?
Just out of curiosity, I don't exactly get the reason why -base and -gui are still built as libraries, rather than as frameworks. Sorry if I insulted anyone... Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GNUstep Native Framework Support
Hello everybody I know there have been tons of discussions and flames on this topic, but this time I have a solution for it. For details, please read http://openspace.adlerka.sk/NativeFrameworks and tell me your opinion: is it worth bothering about further, or just blow the whole thing in the wind. And please don't stone me if you don't agree with the details... Best regards Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Native Framework Support
I wanted to avoid using some platform-specific hacking in order to extended support to the platform hated by any serious developer: Windows. Quoting Nicola Pero <[EMAIL PROTECTED]>: > > * ObjC software is not always invoked from the command line ... eg if > your ObjC software is a package (linked to some frameworks) that you want > to load inside a program written in another language (typically Java or > Python), you can't execute any prior script to set up the library path to > match the exact frameworks linked into the code you're loading; you'll > just be loading the ObjC code using C calls to the linker libraries and > running it. That makes everything lot more complex in this case -- I > suppose all language interfaces would have to have custom code that would > actually manually load all the required frameworks using the linker > libraries ? That would be quite messy. Currently, instead, all this is > done automatically by the linker and is really nice. :-) I hadn't thought of that .. ^_^; oops. Anyways, I think it could be circumvented like this: implement our own "front-end" to the linker. In more detail, my ideas run like this: - every wrapper would contain information on what frameworks it depends on. Frameworks would also contain additional dependency information. - our linker would look through the dependency hierarchy and resolve all framework locations. - the linker could be implemented as a thin C-library which would be used by code which would want to load ObjC frameworks/bundles (e.g. ldfworks.c and any ObjC language-bridge). Instead of using 'dlopen' they would use our (for example) 'GSLoadBundle()'. This function would do the above lookups and afterwards set up the LD_LIBRARY_PATH of the process in which it operates to correctly include the frameworks. Finally, it would simply invoke dlopen. (While writing this e-mail a joky idea came to me: what if we didn't build apps/tools as standalone apps, but instead build them as shared libraries. Running an app/tool would be then be done by invoking our specialized mini-C-program which would simply load the target program's relocatable code into it's address space and transfer control to it. The point of doing this is that we can do arbitrary setups before the code is actually loaded and run, and the only difference that target program would see is that it's stack backtrace would be one level deeper. It's just a rough idea, but it could work... and on top of that be portable... :-D (though, again, debugging issues...)) > * In some cases, LD_LIBRARY_PATH is ignored on Unix. For example, by > tools that can be run as root by any user (setuid). For those, the only > possible solution is having symlinks and then running ldconfig. :-( True, no solution possible here... damn... However, even with today's symlinks setuid ObjC binaries would require me to put my paths into /etc/ld.so.conf - symlinks alone don't suffice, as the linker ignores LD_LIBRARY_PATH. In other words: the functionality is broken already today. > * The recent trends in GNUstep users are that we should try avoiding > shell/C wrappers and relying on LD_LIBRARY_PATH and other such variables. > Most people are more worried about being able to deploy the software so > that it runs out of the box and can't be considered as friendly as native > applications, rather than about frameworks being more "real". ;-) > The wrapper mechanism would do it's own env var setup, so "out of the box functionality" actually is ensured. There might, however, be problems if a program plays around with it's LD_LIBRARY_PATH, but this problem exists today as well, as GNUstep uses LD_LIBRARY_PATH for setting up the linker search path to include the directories with symlinks to frameworks. > * Wrappers are slow. We used to have wrappers for all our ObjC tools, > but that way whenever you write a command-line in ObjC you'd get penalized > a lot compared to a native C tool. You can't match the speed of a native > C tool such as 'sed' or 'grep' if you have wrappers -- the wrapper itself > will require at least an additional process creation, which is a > considerable overhead for a light command-line tool. So we managed to > remove the wrappers, and nowadays writing ObjC command-line tools should > be possible and they should be reasonably comparable, in speed, to native > C tools. :-) I'd personaly disagree here. Compare the speed penalty of an additional exec against the dynamic-linker having to load giant libraries (which gnustep-base is). I use a 533MHz Transmeta and GNUstep tools already _have_ a significant speed penalty. When I run "grep" I instantly get a response. Running make_strings takes roughly 0.5 seconds. I think a few additional miliseconds taken up by ldfworks.c get completely lost in the giant startup gap. > > I don't mean to stop the debate though, and not necessarily to discourage > you. Maybe we could still have it as an option if people like it. :-) > > Let's hear w
Re: GNUstep moving forward
I've been with GNUstep over several years now and I agree that it is currently encountering a state of slow stagnation. Quoting Gregory John Casamento <[EMAIL PROTECTED]>: > GNUstep has been relatively stagnant over the last several months and it has > become a cause for concern for me. > > I've been doing a lot of thinking and have compiled a list of things I > believe > that GNUstep needs to address to stay on top of things. The list follows: > > 1) More apps. Many of the following points will help with this, but this is > very important. I'm working on this, but I've only got one life and a day only has 24 hours. :-) I'd propose making a list of "things being developed" (I mean _actively_ developed, as in _work_really_being_done_) so that a person willing to do some app/framework/tool/feature for GNUstep could simply have a look at what is being currently done and possibly contact the person in charge so that they can collaborate, or simply find out what's already being done so that several people don't work on the same thing. > 2) Better theme support. Integration of Camaelon into the core gui library > if possible I agree, looks does matter. > 3) Better win32 support. Many companies are really eager to port their > legacy > NeXTSTEP/OPENSTEP or Cocoa apps to GNUstep under Windows. The prospect of > Linux and BSD support appeals to them as well, but not as much as Windows. > I currently have two companies with whom I am talking about this. 1000% agree: my company too would profit from GNUstep being nice and smooth under Windoze (although our primary target is UNIX-like systems). > 4) Better distro support. We really need to get GNUstep into as many > distributions as possile, this will ramp up exposure of GNUstep to more > people > and help us get more developers and users. Yes, and I'd like to add to this: we need to simplify the way people report bugs. Remember the BugNeXT application? (http://www.levenez.com/NeXTSTEP/Demos.html) It's was a simple and fast way how to bug the developers at NeXT about their. If others agree, I'll hack a BugStep together in a few moments. > We as a project need to be more adaptive and less resistant to change. More > than anything right now we need to consider the audience we are playing to. > GNUstep needs to be better able to integrate with other environments. > > Additionally, I've noticed recently a trend for certain people to constantly > query the list asking for permission to make this or that change. It seems > that what we need more than anything right now is more action and less talk. > If you are interested in doing something, please do it! :) Got it! :-) > Please think about what I've said and let me know your thoughts. I say the > above out of concern for the community. GNUstep is and always has been a > true > labor of love for me. I want to see it thrive. > > Sincerely, > > Gregory John Casamento > -- CEO/President Open Logic Corp. (A MD Corp.) > ## Maintainer of Gorm (IB Equiv.) for GNUstep. > -- Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
Quoting Gregory John Casamento <[EMAIL PROTECTED]>: > > 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. > Currently I'm working 100% on http://student.fiit.stuba.sk/~kiselkov04/ProjectManager - an new IDE completely from scratch. It currently still lacks many features, but what is done: - bundle extensible project type - allows for arbitrary file layout (through grouping files in abstract `categories' (sort-of like directories, but not really on disk)) - build error interpretation - errors are grouped in a table, double click on a row and the error file opens, highlighting the error line. - fully functional code editor (except for colouring... but I'm working on it) + line/character indication and "Go To Line..." + autoindentation + customizable external command output piping + customizable tab to space conversion Comments are welcome, though please still consider the code practically a tech-demo, I would not have released it for another two weeks (currently working on it about two weeks already) if this discussion would not have come up. As to the other developer tools: - after I finish ProjectManager at least to some degree (or somebody takes over for me, since a day only has 24 hours...) I'm back off to GNUstep Core Data (http://gscoredata.nongnu.org) and over there is an app called DataBuilder which allows users to easily assemble data models for use with GSCoredata. - if there's interrest in an app like ObjectAlloc (a real-time object allocation monitor) I can assemble it in a day or two. I already did it some years ago (though never got to releasing it...), but the idea is still in my head, so it should be a matter of a couple of moments. Regards -- Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
Quoting Adrian Robert <[EMAIL PROTECTED]>: > > On Oct 24, 2005, at 5:08 AM, Sa�o Kiselkov wrote: > > > Quoting Gregory John Casamento <[EMAIL PROTECTED]>: > >> > >> 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. > > Hi, > > > Currently I'm working 100% on > > http://student.fiit.stuba.sk/~kiselkov04/ProjectManager - an new IDE > > completely > > from scratch. It currently still lacks many features, but what is done: > > Why not help out on ProjectCenter? Instead of having two > halfway-useful IDE's, maybe we could have one powerful one.. > > Specific comments below.. > > > > - bundle extensible project type > > Project Center has this. > > > > - allows for arbitrary file layout (through grouping files in abstract > > `categories' (sort-of like directories, but not really on disk)) > > Project Center could use this. XCode has it, so users that also > develop on Apple will grok it (and indeed, would like it). > > > > - build error interpretation - errors are grouped in a table, double > > click on a > > row and the error file opens, highlighting the error line. > > XCode (and I think ProjectBuilder) had this. It would be nice to > enhance ProjectCenter to have it too. > > > > - fully functional code editor (except for colouring... but I'm > > working on it) > >+ line/character indication and "Go To Line..." > >+ autoindentation > >+ customizable external command output piping > >+ customizable tab to space conversion > > You can try writing an editor from scratch, but unless you pump a LOT > of time into it you'll end up with something that someone will shift > away from once they have some real work to do. Project Center has > Emacs integration via gnuclient, and in my opinion this is the most > sensible way to go. Add Vim integration or your other favorite editor, > improve the richness of the interface between IDE and editor, etc.. I > talked to the maintainer of ProjectCenter about this a year and a half > ago, and he had some ideas to move forward, but neither of us got the > time to do it. > > If you are still insistent on this, take a look at > http://www.nongnu.org/codeeditor/ , or TextEdit here: > http://www.nongnu.org/backbone/apps.html . Both would be good starting > points. Alternatively, an idea I had was to bundle > http://emacs-on-aqua.sf.net into a framework so you could have an emacs > pane wherever you needed an editor panel. This would be a bit of work, > but a whole lot less than writing your own editor, and the result would > be truly excellent. (Also, I think the emacs-20-based emacs-on-aqua is > a good base, lighter-weight than the upcoming emacs-23-based port -- > http://emacs-app.sf.net.) > > > > Comments are welcome, though please still consider the code > > practically a > > tech-demo, I would not have released it for another two weeks > > (currently > > working on it about two weeks already) if this discussion would not > > have come > > up. > > I strongly encourage you to think about working on Project Center. > Much of the grunt work that you'll have to redo is already done, it has > a nice clean interface so far, with plenty of scope for extension, and > it's design is fundamentally familiar to Apple developers, so more > widespread adoption is likely. If you still want to explore making > your own IDE for a while, please at least consider integrating some of > your code into ProjectCenter at some point. > > thanks, > Adrian I know that extending ProjectCenter might be a nice and great way to reuse it's code, but personally I'd like to redesign some of it's aspects from grounds up and integrating those changes in PC would be basically redoing much of it, introducing new bugs and a lot of headche than if I did it from scratch. As for the editor: having interfaces to various user-configurable editors is great, but it would be ok to have a usable one in the base package as well... Just have something, extensions can be added later. That's my opinion. -- Saso ___ 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?)
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: --- sections about the core libraries --- - GNUstep-Make - GNUstep-Base - GNUstep-Gui - GNUstep-Back --- sections about GNUstep in a broader view --- - Development Tools - User Environments (etc.) (Perhaps a gnustep-future mailing list would also do the job, but mailing lists have quite limited capacity for larger volume discussions and are not that well manageable.) Anyways, on this discussion people would have a direct way how to propose and discuss new features. A forum moderator could direct the discussion so that it doesn't turn into a flame war. >From the discussion forum's most discussed topics, the steering commitee would compile a list of top-level issues, something like a "roadmap" or a "wishlist" and put it somewhere where people can see it well (a link from the main page or the "Developers" page would be great). Developers interrested in extending GNUstep can gather inspiration from this and start working. Maybe also setting up a page like "Who's Doing What" would be good. Here people working on the hot issues would be listed, so that there won't be several people working on the same issue at the same time, or so that they could work together. What do you think? -- Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
Quoting Serg Stoyan <[EMAIL PROTECTED]>: > On Monday 24 October 2005 21:40, Sašo Kiselkov wrote: > > Quoting Adrian Robert <[EMAIL PROTECTED]>: > > > I strongly encourage you to think about working on Project Center. > > > Much of the grunt work that you'll have to redo is already done, it has > > > a nice clean interface so far, with plenty of scope for extension, and > > > it's design is fundamentally familiar to Apple developers, so more > > > widespread adoption is likely. If you still want to explore making > > > your own IDE for a while, please at least consider integrating some of > > > your code into ProjectCenter at some point. > > > > > > thanks, > > > Adrian > > > > I know that extending ProjectCenter might be a nice and great way to reuse > > it's code, but personally I'd like to redesign some of it's aspects from > > grounds up and integrating those changes in PC would be basically redoing > > much of it, introducing new bugs and a lot of headche than if I did it from > > scratch. > > > > As for the editor: having interfaces to various user-configurable editors > > is great, but it would be ok to have a usable one in the base package as > > well... Just have something, extensions can be added later. > > All you mentioned before has already implemented in ProjectCenter or planned > to be implemented. You can see in Documentaion/TODO file. > > I know I have to post new ProjectCenter development plans and current state. > In short, now I've almost finished redesign bunle management (on-deman > loading of bundles). I come to this decision after I started to work on > editor. Next week I'll be offline(business trip). After that I plan to commit > changes to UNSTABLE_0_5 branch. Do you still have no time to see what the > ProjectCenter is now? > > If you have working fast editor with features toy mentioned before I'll be > glad to redesign ProjectCenter (if it would be sane) and integrate it. > > > That's my opinion. > > -- > Serg Stoyan The code editor is rather fast (I know, I have a slow computer) and quite well separated, basically just two classes: SourceEditorDocument and EditorTextView. There is currently no support for code coloring, however, which is why it's _just_ two classes. After I add support for that, it will be of course more. As for work on PC: I'm sorry, but currently I want to continue PM. I plan to get into a releasable 0.1 state within a week. 0.1 in my terms means: most of it is implemented, though some bits here and there still remain, but what is implemented should be already stable and not crash <- of course this is often just a fantasy :-) But in order to make it mostly true, before releasing an app, I reserve a day or two and "tease" it around - while running in a debugger, I do stuff lots and lots of times repeatedly, do unexpected stuff, do nonsence, and in general "try hard to crash it". :-) I learned this at work, where thanks to that my apps don't segfault and throw out unexpected exceptions anymore. Also following the KISS rule (Keep It Simple, Stupid!) helps a lot. -- Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Possible future Gorm name change
Quoting Gregory John Casamento <[EMAIL PROTECTED]>: > All, > > I have been considering for some time changing Gorm's name to something else. > I believe that some people might find the name a little awkward and some, > particularly on slashdot, commented on it. > > In spite of the fact that other Open Source/Free Software apps have odd > names, > GIMP being possibly the most glaring example, some people seem to dislike the > Gorm name. > > I wanted to take the opportunity now, rather than later, to ask if anyone has > any suggestions they would like to make regarding the name of the > application. > My personal favorite, if the name were to be changed, is InterfaceCreator > since > this goes very well with ProjectCenter. Perhaps change it to something which doesn't have a "Gor" combination - that makes the name sound a bit darkish and brings up associations in my head such as "gore", "growl", "grunt", etc. But that's an unimportant little thing and I'm fine with Gorm's current name as well. Just please don't change it to "InterfaceCreator" or another silly tongue twister. If change, then something short and simple to remember. Look at other IDE's names: Xcode, Eclipse, NetBeans, Code::Blocks, Visual Studio, Lazarus, etc. - they're all relatively short and sound quite nice (also to non-English speakers). > On Cocoa you have PB and IB and on GNUstep you have PC and IC. :) Apple changed ProjectBuilder's name to Xcode a couple of years ago, so that it would be shorter and would sound better. Or perhaps Steve Jobs was tired from pronouncing the lengthy name a thounsand times at expos... :-) > > Anyway... please let me know if you have any substantive (meaning not silly, > stupid or patently unimaginative) ideas regarding a new name. > > Thanks, GJC > > P.S. I personally like the Gorm name, but I wanted to poll the community > before > the next major version of the application comes out. > > Gregory John Casamento > -- Principal Consultant, Open Logic Corp. (A MD Corp.) > ## Maintainer of Gorm (IB Equiv.) for GNUstep. > -- Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Notification once a minute - for a clock...
Quoting Jiva DeVoe <[EMAIL PROTECTED]>:
> So I'm sorta hacking on WildMenus this weekend, and have implemented
> a primitive clock in the menubar... I'm wondering what's the best way
> to get my clock to redraw once a minute? Obviously the menu code
> itself gets linked into each application, so having 20 applications
> all launching their own little background timers to update the
> menubar clock sounds kinda cruddy. What would be the best way to do
> this? I imagine some kind of NSNotification but that also seems cruddy.
>
> (ps: For those who want said functionality - I have been sending
> patches to Michael Hanni, the WildMenus maintainer, so look for a
> release from him eventually.)
>
> --
> Jiva DeVoe
> http://www.devoesquared.com
> PowerCard - Intuitive Project Management for Mac OS X
>
>
This in fact isn't such a big problem. But to get the max efficiency out of it
do it like this:
// if we're not the currently displayed app this method immediately returns
- (void) invokedOnceAMinute
{
if ([NSApp isActive])
{
[self updateClockDisplay];
}
}
// update the clock's display in case it hasn't been updated in the mean time
- (void) appDidBecomeActive
{
[self updateClockDisplay];
}
Regards
--
Saso
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSController and subclasses
I've restarted work on it again lately, so it's going to continue. I've uploaded the latest tarball to http://totorisu.sk/gscoredata.tar.bz2 If you want to, merge it into GNUstep SVN, but I would be happy if I could continue work on it ;-) As for the progress: so mere 15k line of code have been written so far and I estimate that it's going to cost once more that ammount to make it work well. The current status of both the Core Data framework and the Data Builder application is half-finished. -- Saso On 6/6/06, Gregory John Casamento <[EMAIL PROTECTED]> wrote: Wasn't Saso working on a core data clone? Would it be worth it to ask him if he can contribute this, since he recently said that he doesn't have time to work on it? -- Gregory John Casamento - Original Message From: Fred Kiefer <[EMAIL PROTECTED]> To: GNUstep Developer Sent: Monday, June 5, 2006 1:30:12 PM Subject: NSController and subclasses I am still trying to get the Books application to compile with GNUstep. Amongst many other things that are still missing, we also need NSController and the two subclasses NSObjectController and NSArrayController. All these classes have been added to AppKit in MacOSX 10.3 and extended in 10.4. GNUstep still doesn't have them. These classes need key-value coding and observing to be fully functional and NSObjectController also uses some classes from the coredata framework. This lets me doubt, if we really should put these classes into gui. What about having a coredata framework in the GNUstep SVN and add these classes as an extension to that? Any opinions? Fred ___ 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: The need for an official GNUstep desktop
Gregory John Casamento wrote: All, All of this discussion on the list has made my consider that GNUstep needs to resolve this confusion once and for all. Are we a desktop or a development environment? I believe that we can, and should, be both. One of the steps we need to take towards doing this is the creation of another project which will be the official GNUstep desktop. Up until now we've had 4 or 5 projects playing at being the official desktop in an effort to fill the void. I believe that all of this is senseless duplication and that what we need is a *coordinated* effort towards making a cohesive and attractive GNUstep desktop environment. We need to focus on what will make an exciting and easy experience for both users and developers. Whether it is done in the same repository as GNUstep or in a separate one, that's up for debug. Does anyone have any thoughts or ideas on the above? Thanks, GJC -- Gregory John Casamento ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev I'd much rather prefer GNUstep to stay a cross-platform API and development environment, rather than trying to be a bit of everything. It would hurt commercial applicability of GNUstep, such as we do at our company, if I had to deploy tons of other software together with my GNUstep app. Some for of coordination between a full-blown desktop and the GNUstep development framework would be nice, of course, but it should not directly affect GNUstep development. I'd rather see the relationship between GNUstep and it's "official" desktop be something like GTK+ or Qt are to all DEs built on it - they are foundations of them, but is also usable to build stand-alone apps. -- Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: question to backend/gui guru...
[EMAIL PROTECTED] wrote: Selon "Philippe C.D. Robert" <[EMAIL PROTECTED]>: Hi, On 12.09.2006, at 11:29, [EMAIL PROTECTED] wrote: Some of the classes i might use : (picked up from www.gnustep.org/resources/documentation/Developer/Gui/Reference/) NSColor* NSCursor NSEvent NSFileWrapper NSFont*, NSGlyph* NSImage* NSGraphicsContext NSOpenGL* NSResponder NSScreen NSSound At least NSResponder and NSEvent will be very useful. If you use SDL and its event handling then you don't need those classes as well as NSGraphicsContext , NSOpenGL* and friends. Also, how would you want to use NSFont* and NSGlyph* in an OpenGL context? I assume it is a lot easier to use SDL for all this stuff rather than tweaking gui to work w/ SDL. You are still able to use base, of course. I've done that myself. -Phil -- Philippe C.D. Robert http://www.nice.ch/~phip You're probably right. I've read some appkit source files : all theses classes seem to be closely bound to each others... very hard to use one without using some others, and so on. (is this a design choice?)(ie: many classes use some NSPanel to display error message !) I've changed my roadmap : I code my project step by step and i'll add some gnustep classes only when i need them. At end if i really need a display server... well... I'll work on it. Thks Xavier ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev Although that's right, you will miss out all the nice drawing capabilities of the PostScript graphics model, like random path filling, stroking, clipping, affine transforms and other complicated and nifty features. That is, unless you were to use libart or libcairo directly, of course. -- Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
