Re: Cairo as common graphics context
Adam, On 15/03/06, Adam Fedor [EMAIL PROTECTED] wrote: On 2006-03-15 07:53:12 -0700 Stefan Urbanek [EMAIL PROTECTED] wrote: From naive point of view the steps necessary would be: 1. create API for picking graphics context with prefered destination 2. pick ONE graphics library as preffered graphics context library and move it's use (or use of a bundle) into GUI 3. update GUI to use graphics context provided by the graphics library I'm sure you can do that. But then you are requiring more dependancies (particulaly in the GUI, which is not where we want it). Since both cairo and art can draw into a bitmap, it would probably be better just to define an interface between the GUI and back to allow that, then the particular backend would be responsible for doing the work. No, I can't. See below. Looks like all necessary code is already in GNUstep, it is just a matter of rewiring it. But well ... I do not see much into the internals... Oh yes, actually doing the work - well that's the hard part :-) Excuse me, but I take this from you as a little offence with the meaning:do not talk, just code. Following text is not going to be only about the issue, but about general attitude on this list. This attitude is repeating on this list again and again... Yes, for some it might seem that I am just talking on the list and contributing nothing for several past months. If you think so, be it. It is common misundestanding, that only value to an opensource project is programming. I did analysis, found the problem, located code and suggested a solution. It seems to me that this is never valued... Moreover, if you, or anyone else thinks, that my just talking is worthless on this list, let me know and I will stop. You, as the wise project leader should know better than anyone on the list, who is is at home in which parts of GNUstep. Instead of laughing at me (I exaggerate now, so take it with less weight) that I just talk and do not program, you should try to allocate voulenteering resources to the problem according to appropriateness. For me to implement this would mean to dig into the gui and back, as I really do not have a chance how the things are connected. Also note that this would require more discussion of people who developed relevant parts of gui and back to find a solution that would be modular, non-braking and will fit to the libraries. Yes, GNUstep as any other open-source is voulentary project, so the project leader can not force anyone to do anything. Also people have other things to do. But! If I understand the role of project leader correcly, then I think his task is, among others, to allocate resources with redundancy. Or I am wrong? What I was able to do with the time I had, was analysis. I do not code GNUstep anymore and I do not plan to code for GNUstep in the near future... My inputs are not valuable? Again, if yes, then let me know and I will stop just talking on the list. It is all about attitude...which drives the project...to somewhere... Regards, Stefan Urbanek p.s.: With programmers are the only core of the OSS attidute, I can suggest this to my company to fire all analysts, including me, as they are doing nothing, they just meet, talk and draw pictures. p.p.s.:Moreover, this year I have not seen any relevant answer to project-crucial questions I have posted to the list. The only response was from Alex Perez, who just broght the questions to the light again. Whi this attitude, the project is dead. -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cairo as common graphics context
On 16 Mar 2006, at 08:37, Stefan Urbanek wrote: Adam, On 15/03/06, Adam Fedor [EMAIL PROTECTED] wrote: On 2006-03-15 07:53:12 -0700 Stefan Urbanek [EMAIL PROTECTED] wrote: From naive point of view the steps necessary would be: 1. create API for picking graphics context with prefered destination 2. pick ONE graphics library as preffered graphics context library and move it's use (or use of a bundle) into GUI 3. update GUI to use graphics context provided by the graphics library I'm sure you can do that. But then you are requiring more dependancies (particulaly in the GUI, which is not where we want it). Since both cairo and art can draw into a bitmap, it would probably be better just to define an interface between the GUI and back to allow that, then the particular backend would be responsible for doing the work. No, I can't. See below. Looks like all necessary code is already in GNUstep, it is just a matter of rewiring it. But well ... I do not see much into the internals... Oh yes, actually doing the work - well that's the hard part :-) Excuse me, but I take this from you as a little offence with the meaning:do not talk, just code. Following text is not going to be only about the issue, but about general attitude on this list. This attitude is repeating on this list again and again... It appears to me that you are reading into Adam's comments a lot that isn't there. Certainly I didn't take from it anything like the same thing that you did. His use of 'you' looks like the colloquial usage equivalent to the old fashioned use of 'one' as a pronoun, and probably didn't mean/ imply anything about your personal programming skills, but even if it did, that would just seem to say that he assumed you were a programmer ... which is not unreasonable on a developer mailing list. In fact it just looks like a simple response to a technical enquiry in which he suggests a possibly better way of achieving the desired result. As for the 'well that's the hard part' (with smiley) ... I read that as saying that 'just' rewiring could well be a misleading description of the work involved, and an implicit invitation for you to volunteer to do it. All in all, utterly appropriate to a developers mailing list. It doesn't in any way imply that contributions/inputs are not appreciated... you just need to bear in mind the context of the list you are using. p.p.s.:Moreover, this year I have not seen any relevant answer to project-crucial questions I have posted to the list. The only response was from Alex Perez, who just broght the questions to the light again. I don't recall seeing any others this year ... apart perhaps from your 'GNUstep Cocoa compatibility' posting ... which I didn't immediately reply to because I didn't (don't) really understand the diagram. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ANN: GNUstep Base 1.12.0
Adam Fedor wrote: On Mar 14, 2006, at 3:11 PM, Fred Kiefer wrote: Adam Fedor wrote: The GNUstep Base Library, version 1.12.0, is now available. After a SVN update and a rebuild of make and base, I get the follwoing error message when rebuilding gui (make distclean; ./configure; make; make install): Creating GSspell.service/Resources/Info-gnustep.plist... ././shared_obj/make_services: error while loading shared libraries: libgnustep-base.so.1.12: cannot open shared object file: No such file or directory I don't really have any idea. Perhaps a stale link, but I think that would clear up after a while. True, now the problem is gone again. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cairo as common graphics context
Hi Stefan, Stefan Urbanek wrote: On 15/03/06, Adam Fedor [EMAIL PROTECTED] wrote: On 2006-03-15 07:53:12 -0700 Stefan Urbanek [EMAIL PROTECTED] wrote: Looks like all necessary code is already in GNUstep, it is just a matter of rewiring it. But well ... I do not see much into the internals... Oh yes, actually doing the work - well that's the hard part :-) Excuse me, but I take this from you as a little offence with the meaning:do not talk, just code. Following text is not going to be only about the issue, but about general attitude on this list. This attitude is repeating on this list again and again... I think you mail has already been answered by Richard most appropriatly. There was a misunderstanding and surely no offence. When I do answer to your mail it is not about that, but because I should have answered to your mails in the first place. It looks like I am currently the only GNUstep developer working on back and the interaction between back and gui and also specifically on the cairo backend. As Adam already stated some of your ideas are quite interesting and it would be worthwhile to extend GNUstep in that direction. But this will only happen if somebody takes the time to do this. It is not, as your mail may suggest, that Adam as the project lead could just tell some available resource to start working on that. There is nobody available at the moment and even then it would be up to that person to decide itself, what task to work on. Why did I not reply to your mails yesterday and the day before? Because then you would have expected me to actually work on this problem. All that new graphic stuff that Apple did for 10.4 is surely interesting and it would be great to have it in GNUstep as well and cairo may be a way to get there, but somebody has to implement all that. I already have to many open ends in GNUstep development, which I need to finish off first. It surely is not your fault, but currently GNUstep dearly requires developers working on the core libraries. Just look at the amount of changes done this year on gui. In the first three months it was less than on any of the first month of the previous year. Discussions and ideas are important, we all agree on that, but coding also is. And at the moment we don't have enough of the later. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[PATCH] Minor fix in NSWindowController
Hi, Here is a little patch to have proper window controller deallocation when used in document architecture context. It is based on an initial bug report by Saso Kiselkov. I'm going to briefly summarize Cocoa documentation… When you are using a window controller within the document achitecture context (NSDocument + NSDocumentController), - -releasedWhenClosed value isn't taken in account : when a window is closed, the window is always released by the window controller, itself released by the document object. That's not true for a window controller used alone. To enter in the details, in our case, the current NSWindowController code includes a dubious retain call on its window ivar (within _windowWillClose: private method). This prevents the window to be correctly deallocated unlike its window controller. The -retain call currently presents code is unbalanced, that results in a memory leak and sometimes in a segmentation fault. For example… You decide to use a toolbar with your document window and the document object plays the role of the toolbar delegate. When the document window is closed, the window controller and the document object are released, but the document window is not (and its toolbar neither). The next time you are going to open or create an identical document, a new document window will be created with a fresh toolbar. When you are going to manipulate this toolbar, it will try to propagate its state to other toolbars still in use with the same identifier. At this moment, the undeallocated toolbar will try to ask its delegate for items, but the delegate (document object) has already been deallocated, this invalid pointer access will then trigger a segmentation fault. The fix just consists to remove the -retain call, then everything is properly deallocated on document window closing. Since I don't really understand the explanation in the comment related to the offending line), I'm perhaps missing an important detail in with this patch, yet I have experienced no issue in my tests with this fix. Thanks, Quentin. WindowController.patch Description: Binary data -- Quentin Mathé [EMAIL PROTECTED] ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
