Re: Plans for change....
On 12/17/06, David Wetzel <[EMAIL PROTECTED]> wrote: > All, > > I've written up a short list of things that I want GNUstep to accomplish > in the year to come: > > As Chief maintainer, it is up to me to determine the > direction of the project. To me, that sounds very reasonable. Themes are very important. Dynamic layout/sizing like Renaissance does is also very important. I see no real reason to use hardcoded Y/X values like done in NIB files. Well, hardcoded position does make localization look better considering the languages are quite different in west and east. Yen-Ju Dave -- _ _ _(_)(_)_ David Wetzel, Turbocat's Development, (_) __ (_) Buchhorster Strasse 23, D-16567 Muehlenbeck/Berlin, FRG, _/ \_ Fax +49 33056 82835 Phone +49 33056 82834 (__) http://www.turbocat.de/ ___ 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: Plans for change....
On 12/17/06, David Wetzel <[EMAIL PROTECTED]> wrote: Yen-Ju Chen wrote: > Well, hardcoded position does make localization look better > considering the languages are quite > different in west and east. Wrong, because auto-layout will take care of that. I have seen some Mac Apps that had too big German labels... If text is too big, it is because it has no localized nib file. More often, I see labels with too many space behind because Chinese is usually shorter than English. I think this argument falls into the category as the scroll bar should be on the right or left. There is no solution to make everyone happy. Yen-Ju -- _ _ _(_)(_)_ David Wetzel, Turbocat's Development, (_) __ (_) Buchhorster Strasse 23, D-16567 Muehlenbeck/Berlin, FRG, _/ \_ Fax +49 33056 82835 Phone +49 33056 82834 (__) http://www.turbocat.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Plans for change....
On 12/17/06, David Wetzel <[EMAIL PROTECTED]> wrote: Yen-Ju Chen wrote: > I think this argument falls into the category as the scroll bar > should be on the right or left. > There is no solution to make everyone happy. Maybe you should read [1]. It is very simple. Scrollers are always parts of a scrollview. A theme can change the layout. This was already possible on slow Amigas so for a true OO environment on much faster machines it should be a piece of cake. [2] I do know Renaissance. I use scroll bar as an example only to show that there is no way to have everyone agree on everything. If GNUstep decide to adapt auto-layout, people from Cocoa may start to complain because they use hard-coded position and their nib file cannot convert to gorm file. If GNUstep support two kind of layouts, it just add more burden on developers and may confuse users. By the way, I remember GNUstep has something like GSVBox and HBox for auto-layout. Personally, I think GNUstep try to please everyone and start to lose its personality. In the end, no one is completely happy. If an application work well, like GNUMail, who care about it is auto-layout or not. Anyway, unless someone plans to write an implementation, there is no use to argue it further. :P Yen-Ju [1] http://www.gnustep.it/Renaissance/Screenshots.html [2] http://www.sasg.com/mui/features.html -- _ _ _(_)(_)_ David Wetzel, Turbocat's Development, (_) __ (_) Buchhorster Strasse 23, D-16567 Muehlenbeck/Berlin, FRG, _/ \_ Fax +49 33056 82835 Phone +49 33056 82834 (__) http://www.turbocat.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Plans for change....
This is a news of GTK+ to be ported on Mac natively without X11. http://www.oreillynet.com/mac/blog/2006/12/illuminous_meet_gtk_1.html The interesting part is the comment. I would say the same comment may apply to GNUstep on Windows. If GNUstep doesn't gain popularity on its native platform (Unix, and probably Cocoa), there is no way to gain popularity on other platforms. Yen-Ju ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
On 12/25/06, Fred Kiefer <[EMAIL PROTECTED]> wrote: Gregory John Casamento schrieb: > Richard, > > The reasons behind the move to Cairo are as follows: > > 1) Cairo is being used by a number of other projects. It is very stable and well maintained. > 2) Cairo has been ported to a number of other operating systems, including windows and has a large number of output targets. This way, Cairo would do much of the heavy lifting for us with regards to getting things to render acceptably on other platforms. > > I agree with what Richard is saying here as well. > Looks like everybody agrees with Richard:-) So let's focus on the cairo backend for now and when it is finished deprecate xlib and art, but let them stick around for some time afterwards. Things to be done for the cairo backend: - Test with the latest cairo release. - Sort out copying from one cairo GState onto itself. - Get transparent images working. I guess this is the reason why transparency does not work in Cairo backend: cairo backend draw everything directly on xwindow. In -gui, an image is often draw on a hidden window, then composite on the destination. Because cairo backend draw directly on xwindow first, it loses the alpha value. Then when it is composited to the destination, the transparent part becomes the background of the hidden window. I have a copy of cairo backend in Etoile project: http://svn.gna.org/viewcvs/etoile/branches/yjchen/etoile_back/ It basically draw on the x11/XWindowBuffer first as what art backend does. Therefore, it keeps the alpha value for composition. The modification is very little. You can check out README.etoile_back. A simple diff is sufficient to see the difference of source code. There are some minor issues here and there, though. Happy holidays. Yen-Ju There is more, but these I remember from the top of my head. Cheers, 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: Proposal to deprecate Xlib backend
On 12/26/06, Fred Kiefer <[EMAIL PROTECTED]> wrote: Yen-Ju Chen schrieb: > I guess this is the reason why transparency does not work in Cairo > backend: > cairo backend draw everything directly on xwindow. > In -gui, an image is often draw on a hidden window, then composite > on the destination. > Because cairo backend draw directly on xwindow first, > it loses the alpha value. > Then when it is composited to the destination, > the transparent part becomes the background of the hidden window. > > I have a copy of cairo backend in Etoile project: > http://svn.gna.org/viewcvs/etoile/branches/yjchen/etoile_back/ > It basically draw on the x11/XWindowBuffer first as what art backend does. > Therefore, it keeps the alpha value for composition. > The modification is very little. > You can check out README.etoile_back. > A simple diff is sufficient to see the difference of source code. > There are some minor issues here and there, though. > Great, this resolves the transparency issue! I added your changes for this to the official GNUstep cairo backend. I did not take over your changes to x11, on which I need to take another look. Don't bother with the x11 part. It is just for some experimental stuffs. You also have a change to add the freetype2 libraries and settings to the configuration. This should not be needed if cairo is configured correctly. Could you please type in "pkg-config --libs cairo" at a command prompt to see if this includes freetype or not? I have problem with linking to freetype2 before. I will try it again. I also added you endianess change, hope I did get it correct. I am not sure I did this one right because sometimes I see weird colors here and there. Again, it is just some experiments I were working on. As you have the unbuffered code commented out yourself, I did not take it over. And the NSClipView change is clearly a hack. We need to resolve the actual issue behind it. The unbuffered stuff is from art backend. But frankly, I don't really understand the difference between the non-retained, retained and buffered window. So, just ignore it for now. You can treat the NSClipView category as a not-so-elegant implementation. GNUstep-gui try to save time by copy old area to new position. For a not-so-good implementation, it probably just ask backend to draw everything again. And it is what this category does. :) Yen-Ju With images now drawn transparent you will see that many images get flipped. I will have to take another look into the horrible compositeGState:... method to sort this out. If we are lucky the clip view issue will get resolved by that as well. The next thing to investigate will than be the text drawing, as the metrics seem to be wrong here. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
On 12/28/06, Hubert Chan <[EMAIL PROTECTED]> wrote: On Thu, 28 Dec 2006 00:38:18 +0100, Guenther Noack <[EMAIL PROTECTED]> said: [...] > I could also imagine that a clear indication that xlib is deprecated > may help people outside the GNUstep project. For example when looking > at Etoile, there are at least the MultimediaKit and the > XWindowServerKit which directly talk to X11 (MMKit displays the > Mplayer window in a GNUstep window). For authors of projects like > these two, it may be very helpful to know that they won't have to > support xlib in the future. AFAIK, Etoile still needs to talk to X11 directly for those functions. They are mostly for things that the *Step API does not handle (e.g. switching desktops, embedding, etc.). I think people are talking about using X11 for drawing, not window and even handling in this case. So deprecating x11 backend does not affect the use of X11. Yen-Ju -- Hubert Chan - email & Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA ___ 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: Making release of gui 1/13/2007
On 12/29/06, Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: On 29 Dec 2006, at 00:37, Fred Kiefer wrote: > Gregory John Casamento schrieb: >> >> I would like to shoot for making a release of gui on 1/13/2007. >> > > I am currently working on a rework of NSDocument to include all the > new > MacOS 10.4 methods. Should I try to get these changes in before the > release or after it? > > These changes need to break backwards compatibility as loads of new > ivars need to be added. You will have to recompile all applications > using subclasses for NSDocument. > As I plan to do similar breaking of backwards compatibility over the > next few months, it might be worthwhile to group them together into > one > release. I've been fairly convinced by recent arguments about releases (emails from packagers etc) that we make our new releases too frequently, and that what we should be doing is making less frequent new releases (with new features and api/abi changes), but more frequent bugfix releases (ie where no api/abi changes are made, but bugs are fixed). So I would surely agree with making bugfix releases of gui and back early in january (I've been planning to do base anyway), but I think we should save all the api/abi changes for a later release somewhere six to twelve months away. Of course the downside if this is that we need to backport bugfixes from trunk to the current stable branch of gui/back ... which is tedious (but a lot less work than doing the original fixes). The positive advantage is that by lengthening the interval between new releases we can try to make all the api/abi changes we need together in one go. In the base library I would really like to get it to a state where we have changed all classes etc so that we no longer need to break backward compatibility in any release (ie have changed ivar layouts etc so that all classes we are ever likely to extend can be extended without changing the size of the instances or the nature of any public/protected ivars). With the gui library that may not yet look like a reasonable goal, but we certainly want to be able to make future releases without breaking backward compatibility if we can. As far as giving people access to the latest code in trunk goes ... we have automated snapshots which provide that. Or we could adopt a policy of formally having two sets of releases on the go, stable and unstable, and make it VERY clear that the unstable releases are only for people who are actually willling to contrinute bugfixes/patches for any problems they find. Or we could keep 'preferred'' snapshots on the ftp site ... ie save a set of snapshots once a month, so that people can build to a particular month's snapshots rather than the daily ones ... and know that the set of snapshots they used will remain available on the site for (say) a year, and they can tell people to grab that set of snapshots in order to use their application. My personal preference is for the dual release strategy ... that way we can publicise ourselves twice as often ... once for each stable release, with a nice list of bugs fixed, and a prominent message to encourage packagers to update the distribution they work with once for each unstable release, with a list of cool new features, and a big message to encourage developers to provide bugfixes/patches I think the gnustep-base is stable and mature enough to do so, but gnustep-gui may not be. Many fix to gnustep-gui still break the backward compatibility. So my suggestion is to make it happen for gnustep-base first. Once everything goes smoothly after a couple cycles, it will be pretty easy to do the same thing on gnustep-gui and gnustep-back. Yen-Ju ___ 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: Call for volunteers: Backporting mySTEP changes
On 3/8/07, Fred Kiefer <[EMAIL PROTECTED]> wrote: I would like to send this mail to the discussion list, but want to gather comments on it from you first. On the FOSDEM we agreed that it would be great to un-fork mySTEP. This surely will be a long process, but there are some easy steps that we may already take now. The first one is to try to backport changes done by Nikolaus Schaller in mySTEP AppKit to GNUstep gui. As both libraries have evolved separately for many years, we are talking about a huge amount of changes here. All of them need to be investigated and somebody has to decide what to do best for each of them. It sounds (a) good project(s) for Summer of Code. Yen-Ju For a licence point of view there is no problem in taking over Nikolaus code. He has signed a copyright assignment to the FSF and agreed to have his changes merged back into GNUstep. The mySTEP source can be found at http://www.quantum-step.com/download/sources/ As this really is a huge task, I would like to split it up between different developers. taking over a few of these changes could be a nice way to get started with GNustep. If you are willing to work on this, I can provide you with all the details you need. Before somebody starts on this, we need to make sure that we have a copyright assignment from him/her, otherwise we would have to investigate each change to see if there was more involved than just copying. I can see different type of changes that need to be addressed: 1. New MacOSX classes in mySTEP These could just be taken over to GNUstep. But even that will require a substantial amount of work. - Split up into separate files for each class. - Change the header into the standard GNUstep form. - Reformat to conform with the GNUstep coding standards. (Richards tool objctidy may help here) - Check each method (name, parameters and implementation) and, if possible, add to the implementation. - Document the limitations in the header file Header files in mySTEP: NSAnimation.h NSColorSpace.h NSDatePicker.h NSDatePickerCell.h NSFontDescriptor.h NSGlyphGenerator.h NSLevelIndicator.h NSLevelIndicatorCell.h NSPersistentDocument.h NSSegmentedCell.h NSSegmentedControl.h NSShadow.h NSSpeechRecognizer.h NSSpeechSynthesizer.h NSStatusBar.h NSStatusItem.h NSTextList.h NSTextTable.h NSTokenField.h NSTokenFieldCell.h NSTreeController.h (I even my have missed a few) 2. New MacOSX methods to existing classes Quite often it is just possible to directly add these new methods to the GNUstep header and implementation files. Of course, adopting the formatting in the process :-) When adding the method to the header, we have to add the proper version specific macro around it. That way the new method will only be visible when the correct version of the AppKit is requested. In some cases it is advisable to change other methods as well to make use of the new ones. When changing ivars or enumerator types we need to make sure to keep backward compatibility when reading archives. This kind of methods may exist in almost all classes, even the one I already went through, although in this case it is less likely. 3. Changes to GNUstep mySTEP has a few correction and additions to methods that are already implemented in GNUstep. We should try to extract as much of these as possible. On the other hand have we fixed a lot of bugs in GNUstep since the fork. We don't want to loose these fixes. Quite often there are also two independent implementations of methods in GNUstep and mySTEP, so no benefit may be gained by merging them. This surely is the hardest case and should be done very carefully. I plan to work on NSWindow, NSEvent and NSMenu next (in this order). Cheers, 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: Problem with gnustep trunk
On 3/12/07, Fred Kiefer <[EMAIL PROTECTED]> wrote: Philippe Roussel wrote: > On Mon, Mar 12, 2007 at 06:56:18PM +0100, Philippe Roussel wrote: [snip] Sorry, I was wrong. This seems to be a totally unrelated problem to the gui changes I recently made. Actually I am getting a similar problem for each GNUstep application I start up. It reports: 007-03-12 22:54:13.577 GSTest[29400] File NSUserDefaults.m: 552. In [NSUserDefaults +standardUserDefaults] Improper installation: No language locale found Every other time I start an application it then also complains that the main Gorm file could not be loaded or an alert is displayed with the text: NSInternalInconsistencyException: unable to contact GDNC server - please check that the gdnc process is running. I attempted to start it at '/usr/GNUstep/System/Tools/gdnc' I had some weird problems after installing GNUstep from trunk last Sunday. But after re-compile every application, it turns out to be fine. I guess it just breaks the backward-compatibility. The error regarding to NSUserDefaults is still there, though. Yen-Ju Here is the backtrace I get from this: #0 0xb7f7f410 in ?? () #1 0xbf9e8aec in ?? () #2 0x0006 in ?? () #3 0x737f in ?? () #4 0xb76ff060 in raise () from /lib/libc.so.6 #5 0xb7700801 in abort () from /lib/libc.so.6 #6 0xb7c9a536 in _NSAppKitUncaughtExceptionHandler (exception=0xadbe640) at NSApplication.m:144 #7 0xb799508a in -[NSException raise] (self=0xadbe640, _cmd=0xb7f4c010) at NSException.m:834 #8 0xb7e1cf91 in -[_GSWorkspaceCenter init] (self=0x87e3b70, _cmd=0xb7bc0848) at NSWorkspace.m:283 #9 0xb79d2131 in +[NSObject new] (self=0xb7f4be60, _cmd=0xb7f4bf68) at NSObject.m:1268 #10 0xb7e1dd27 in -[NSWorkspace init] (self=0x87e6a10, _cmd=0xb7f4bfd0) at NSWorkspace.m:626 #11 0xb7e1db44 in +[NSWorkspace sharedWorkspace] (self=0xb7f4bd60, _cmd=0xb7ebc960) at NSWorkspace.m:595 #12 0xb7c9d935 in -[NSApplication finishLaunching] (self=0x8513040, _cmd=0xb7ebca48) at NSApplication.m:1022 ---Type to continue, or q to quit--- #13 0xb7c9f0d2 in -[NSApplication run] (self=0x8513040, _cmd=0xb7eb4ec8) at NSApplication.m:1349 #14 0xb7c8d5d1 in NSApplicationMain (argc=1, argv=0xbf9e9094) at Functions.m:72 #15 0x08048a36 in main (argc=Cannot access memory at address 0x737f ) at main.m:30 Once it did even display an editor for the user defaults, which is something I didn't even know we had. I would say some recent change to base must have caused this. No idea if it was the one by Richard or the one from Nicola. Cheers, 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: Summer of Code 2007
On 3/16/07, Nicola Pero <[EMAIL PROTECTED]> wrote: > But... for the sake of the Google SoC, it's probably best if we concentrate on those areas in > which we are sorely in need of help. Currently, a Renaissance GUI builder would be > interesting, but not essential. It's kind of an upsetting answer for me, but I'll refrain from submitting it as a project then. While I agree with Gregory that it would be better to support Renaissance in Gorm, for SoC, which only last a summer and depends on student's interest, we should not block the option of Renaissance GUI builder. 1. Duplicate work will become an issue only when there is a student who are interested in it. 2. Even there is a student who is interested in it, Nicola can keep the GUI builder modular in case in the future, GNUstep want to support Renaissance in Gorm. So if this Renaissance GUI builder can be more or less in the similar structure of Gorm, or even use the same interface for bundle, to me, it should be an option for students. It is just my 2 cents. :) Yen-Ju 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: Please digg this, we want GNUstep's Summer of Code participation's place in the limelight!
On 3/19/07, Stefan Bidigaray <[EMAIL PROTECTED]> wrote: It seems like the votes have stagnated! I'd like to see this go to the front page, yet we only have 39 diggs so far, I can't believe there are only 39 people that read these mailing lists who are interested in GNUstep. I'm not sure how many diggs we need to get to the front page, but I think it's 40, which means we only need 1 more vote, come on people! dzone.com may be more focus on developers. Let me see whether I can put it on the blog. Yen-Ju Just do it! Stefan ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problem linking on MAC OSX
On 4/11/07, amit hetawal <[EMAIL PROTECTED]> wrote: [snip] > > > > Hello all, > > I have a make file which looks like: > > CC=/usr/bin/gcc > > CPPFLAGS=-c -g -I/usr/local/Coral/include > > -I/Users/hetawal/coral-3.7.5-public/custom > > LDFLAGS=-L/usr/local/Coral/lib -lcoral -lpcap -lhashtab -lz -lstdc++ > > OBJECTS=coral_test.o \ > > recycle.o \ > > lookupa.o \ > > hashtab.o > > TARGET=coral > > > > $(TARGET): $(OBJECTS) > > $(CC) -g -o $(TARGET) $(OBJECTS) $(LDFLAGS) > > > > coral_test.o: coral_test.c Makefile > > $(CC) $(CPPFLAGS) coral_test.c I may be totally wrong here. But where are the source codes of your recycle.o, lookupa.o and hashtab.o ? I only see the coral_test.c. Yen-Ju > > > > clean: > > rm -rf $(OBJECTS) $(TARGET) > > > > but its always giving me error as : > > /usr/bin/gcc -c -g -I/usr/local/Coral/include > > -I/Users/hetawal/coral-3.7.5-public/custom coral_test.c > > coral_test.c: In function 'removeall': > > coral_test.c:68: warning: comparison between pointer and integer > > coral_test.c: In function 'getStatusValue': > > coral_test.c:76: warning: pointer targets in passing argument 1 of > > 'strlen' differ in signedness > > coral_test.c:99: warning: comparison between pointer and integer > > coral_test.c: In function 'insert': > > coral_test.c:114: warning: pointer targets in passing argument 1 of > > 'strlen' differ in signedness > > coral_test.c: In function 'process_packet': > > coral_test.c:164: warning: pointer targets in assignment differ in signedness > > coral_test.c:165: warning: pointer targets in assignment differ in signedness > > coral_test.c:167: warning: pointer targets in passing argument 1 of > > 'strcpy' differ in signedness > > coral_test.c:168: warning: pointer targets in passing argument 1 of > > 'strcat' differ in signedness > > coral_test.c:169: warning: pointer targets in passing argument 1 of > > 'strcat' differ in signedness > > coral_test.c:171: warning: pointer targets in passing argument 1 of > > 'strcpy' differ in signedness > > coral_test.c:172: warning: pointer targets in passing argument 1 of > > 'strcat' differ in signedness > > coral_test.c:173: warning: pointer targets in passing argument 1 of > > 'strcat' differ in signedness > > coral_test.c:187: warning: assignment makes pointer from integer without a cast > > coral_test.c:188: warning: assignment makes pointer from integer without a cast > > coral_test.c: In function 'main': > > coral_test.c:341: warning: pointer targets in passing argument 1 of > > 'strlen' differ in signedness > > /usr/bin/gcc -g -o coral coral_test.o recycle.o lookupa.o hashtab.o > > -L/usr/local/Coral/lib -lcoral -lpcap -lhashtab -lz -lstdc++ > > /usr/bin/ld: Undefined symbols: > > __Unwind_Resume > > collect2: ld returned 1 exit status > > make: *** [coral] Error 1 > > > > I have tried changing the compiler to g++ and the lstdc++ flag but no use. > > > > Can someone help me with this ... > > > > 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problem linking on MAC OSX
On 4/11/07, amit hetawal <[EMAIL PROTECTED]> wrote: What do you mean by that, the source code a for them are present in the same folder. Its like the lookup, recycle is the hash implementation in C and the file is coral_test.c is another custome software for networking wchih in case uses the code of hashes for the working. Hope i make sense... So do i need to chnage anything in my makefile then ? Thanks On 4/11/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: > On 4/11/07, amit hetawal <[EMAIL PROTECTED]> wrote: > [snip] > > > > > > > > Hello all, > > > > I have a make file which looks like: > > > > CC=/usr/bin/gcc > > > > CPPFLAGS=-c -g -I/usr/local/Coral/include > > > > -I/Users/hetawal/coral-3.7.5-public/custom > > > > LDFLAGS=-L/usr/local/Coral/lib -lcoral -lpcap -lhashtab -lz -lstdc++ > > > > OBJECTS=coral_test.o \ > > > > recycle.o \ > > > > lookupa.o \ > > > > hashtab.o > > > > TARGET=coral > > > > > > > > $(TARGET): $(OBJECTS) > > > > $(CC) -g -o $(TARGET) $(OBJECTS) $(LDFLAGS) > > > > > > > > coral_test.o: coral_test.c Makefile > > > > $(CC) $(CPPFLAGS) coral_test.c You have a rule to generate coral_test.o, but not recycle.o, lookupa.o, hashtab.o. Based on your error messages, these three are not complied. Am I missing something ? I always use gnustep-make, even on Mac. It makes life much easier. Yen-Ju > > I may be totally wrong here. > But where are the source codes of your recycle.o, lookupa.o and hashtab.o ? > I only see the coral_test.c. > > Yen-Ju > > > > > > > > > clean: > > > > rm -rf $(OBJECTS) $(TARGET) > > > > > > > > but its always giving me error as : > > > > /usr/bin/gcc -c -g -I/usr/local/Coral/include > > > > -I/Users/hetawal/coral-3.7.5-public/custom coral_test.c > > > > coral_test.c: In function 'removeall': > > > > coral_test.c:68: warning: comparison between pointer and integer > > > > coral_test.c: In function 'getStatusValue': > > > > coral_test.c:76: warning: pointer targets in passing argument 1 of > > > > 'strlen' differ in signedness > > > > coral_test.c:99: warning: comparison between pointer and integer > > > > coral_test.c: In function 'insert': > > > > coral_test.c:114: warning: pointer targets in passing argument 1 of > > > > 'strlen' differ in signedness > > > > coral_test.c: In function 'process_packet': > > > > coral_test.c:164: warning: pointer targets in assignment differ in signedness > > > > coral_test.c:165: warning: pointer targets in assignment differ in signedness > > > > coral_test.c:167: warning: pointer targets in passing argument 1 of > > > > 'strcpy' differ in signedness > > > > coral_test.c:168: warning: pointer targets in passing argument 1 of > > > > 'strcat' differ in signedness > > > > coral_test.c:169: warning: pointer targets in passing argument 1 of > > > > 'strcat' differ in signedness > > > > coral_test.c:171: warning: pointer targets in passing argument 1 of > > > > 'strcpy' differ in signedness > > > > coral_test.c:172: warning: pointer targets in passing argument 1 of > > > > 'strcat' differ in signedness > > > > coral_test.c:173: warning: pointer targets in passing argument 1 of > > > > 'strcat' differ in signedness > > > > coral_test.c:187: warning: assignment makes pointer from integer without a cast > > > > coral_test.c:188: warning: assignment makes pointer from integer without a cast > > > > coral_test.c: In function 'main': > > > > coral_test.c:341: warning: pointer targets in passing argument 1 of > > > > 'strlen' differ in signedness > > > > /usr/bin/gcc -g -o coral coral_test.o recycle.o lookupa.o hashtab.o > > > > -L/usr/local/Coral/lib -lcoral -lpcap -lhashtab -lz -lstdc++ > > > > /usr/bin/ld: Undefined symbols: > > > > __Unwind_Resume > > > > collect2: ld returned 1 exit status > > > > make: *** [coral] Error 1 > > > > > > > > I have tried changing the compiler to g++ and the lstdc++ flag but no use. > > > > > > > > Can someone help me with this ... > > > > > > > > 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 > > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Moving GNUstep applications to GPLv3
On 6/29/07, Gregory John Casamento <[EMAIL PROTECTED]> wrote: Fred, Since the code is copyrighted by the FSF, I don't believe that we need to contact any of the original contributors to make the change. The licensing is entirely at the discretion of the FSF. Maybe it is worth to wait and see how other big projects do, like GCC and GNOME. And see how it affects some aspects where GNUstep will be used, like web services (GNUstepWeb) or embedded system (mSTEP). This article may be worth to read: http://www.thejemreport.com/mambo/content/view/317 It is clearly against GPLv3, though. Yen-Ju Later, GJC -- Gregory Casamento - Original Message From: Fred Kiefer <[EMAIL PROTECTED]> To: GNUstep Developers Sent: Wednesday, June 27, 2007 4:09:37 AM Subject: Re: Moving GNUstep applications to GPLv3 I support this change as well. We already have the choice for the user of the library in there: This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. What I am not sure about is, whether we are able to change the license for old code, where the contributor is no longer in contact with us. Does anybody know about this case? Cheers, Fred Gregory John Casamento wrote: > Great! What you explained is the intention. > > Later, GJC > -- > Gregory Casamento > > - Original Message > From: Nicola Pero <[EMAIL PROTECTED]> > To: Gregory John Casamento <[EMAIL PROTECTED]> > Cc: GNUstep Developers > Sent: Tuesday, June 26, 2007 8:23:27 PM > Subject: RE: Moving GNUstep applications to GPLv3 > > >> If we decide to move to the new license, then my opinion on the best way for the >> project to proceed is to change the license of our applications (GWorkspace, Gorm, >> etc) within GNUstep itself to the GPLv3 license. All of the libraries should >> remain LGPL. > > You probably mean that the software which is currently under GPLv2 will be > moved to GPLv3, and software that is currently under LGPLv2 will be > moved to LGPLv3. > > I would personally support and welcome this change. > > 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
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
Re: Project Center status, or lack thereof...
On 7/8/07, Sašo Kiselkov <[EMAIL PROTECTED]> wrote: -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 I share the same view of GPL3 as Saso mostly. There is a GNUstep Non-FSF project: https://gna.org/projects/gnustep-nonfsf/ If ProjectCenter is moved to this Non-FSF project, it will stay in GPL2 in case FSF decides to move the whole GNUstep into GPL3. But I think it is the decision of the future maintainer. So I will stop here. :) Yen-Ju - -- 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
Use gnustep-make for SimpleWebKit on Mac
I use gnustep-make on Mac and GNUstep. Here is a patch to make it work for SimpleWebKit. I know there is a xcode project for Mac. So developers can decide whether to use this patch. Index: SWKBrowser/GNUmakefile === --- SWKBrowser/GNUmakefile (revision 25328) +++ SWKBrowser/GNUmakefile (working copy) @@ -2,8 +2,13 @@ APP_NAME = SWKBrowser +ifeq ($(FOUNDATION_LIB), apple) ADDITIONAL_GUI_LIBS += \ - -lSimpleWebKit + -framework SimpleWebKit +else +ADDITIONAL_GUI_LIBS += \ + -framework SimpleWebKit +endif SWKBrowser_OBJC_FILES = \ main.m \ @@ -23,4 +28,4 @@ include $(GNUSTEP_MAKEFILES)/aggregate.make include $(GNUSTEP_MAKEFILES)/application.make - +-include GNUmakefile.postamble And this is the SWKBrowser/GNUmakefile.postamble: after-all:: ifeq ($(FOUNDATION_LIB), apple) @cp -f SWKBrowser-Info.plist $(APP_NAME).app/Contents/Info.plist endif ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Use gnustep-make for SimpleWebKit on Mac
On 7/15/07, Riccardo <[EMAIL PROTECTED]> wrote: Hi, On 2007-07-15 20:06:00 +0200 "Yen-Ju Chen" <[EMAIL PROTECTED]> wrote: > Thanx. But the SWKBrowser/GNUmakefile.postamble > should use 'tab' instead of 'space'. Otherwise, it will break. > I think your text editor converts 'tab' into 'space' automatically. possibly, also the patch didn't apply for me and I had to retype it or do copy&paste so maybe I missed something there. Fixed. Thanx. > I suspect it is because there are WebKit and SimpleWebKit on Mac. > SimpleWebKit/WebKit.h uses , > which may refer to Apple WebKit instead of SimpleWebKit. > Therefore, it mess up the compiler. > My suggestion is to use for all SimpleWebKit > headers. I'm not sure there. Having "WebKit" makes compatibility easy and I have seen Nikolaus running SWK on top of cocoa appkit (which is also the way he currently tests it, since both GNUstep and myStep are incomplete or buggy), but by ising directly XCode and not GNUstep make. What changes, I don't know. Maybe you can test subclassing WebView with XCode and see. I include everything in the example I sent and you just need to include PlainWebView.h and PlainWebView.m in xcode. I didn't see anything suspicious in the SimpleWEbKit codes. That's why I suspect the linking problem, but I may be wrong. Yen-Ju -R ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Moving to GPLv3
On 7/18/07, Adam Fedor <[EMAIL PROTECTED]> wrote: On Jul 11, 2007, at 7:08 AM, Gregory John Casamento wrote: > All, > > I am going to start reviewing those parts of GNUstep that I am a > direct contributor to for movement to the GPLv3 or LGPLv3 where > appropriate, namely gnustep-gui and Gorm. Fred, please help me > look at gui for any issues regarding this move. I believe for > those packages it will be simple. > > I would like all of the maintainers for other parts of GNUstep to > do the same and report back if there are any issues with moving to > the new license. > FYI, GNUstep startup distributes the ffcall and libobjc packages along with the core libraries. Neither are GNUstep packages, although libobjc should soon become GPLv3 along with gcc. However since Startup is not itself installed - it's basically just a meta-package with a few configure scripts, I don't think it would be an issue changing the license to v3. I notice that gnustep-make generates code for framework under derived_src/. I think gnupste-make is under GPL2 (and GPL3 later). Usually I saw projects add an exception in license for automatically generated code so that the framework complied by gnustep-make can stay in their own license. Just a suggestion. Yen-Ju ___ 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: FYI and a few questions...
On 7/27/07, Stefan Bidigaray <[EMAIL PROTECTED]> wrote: > So I finally broke down and subscribed to gnustep-dev! I recently > (Wednesday) started working on an implementation of Apple's ScreenSaver > framework so that I can get more acquainted with GNUstep programming. I > figured this framework would be fairly easy to do, which it is, for most > part. I decided to split it in 3 parts, which I think is what I'd have to > do anyway: the framework, a screen saver tool (which I called gssaver), and > a preference module to configure it. > > So far I've managed to complete implementing the ScreenSaverView class and > the SS* functions, but have no idea how to work the ScreenSaverDefaults > class. I most definitely will need some help implementing > ScreenSaverDefaults, but I'm not too worried about it now since the default > screen saver is a blank screen and doesn't need any configuration. > > I still haven't done anything in the preference module front. Since all of > the programming I've done has been at work and my everyday computer I > haven't had access to a GNUstep installation, and haven't been able to use > Gorm to create the interface. I figured I would build the module by hand, > but gave up on that idea since I thought I could learn more using Gorm. For > now, I've kind of put off creating the preference module till I'm done with > the tool. > > The tool, gssaver, is turning out to be a little more complicated than I > initially thought. What I figured I'd do with it is make it an > NSApplication but build it as a tool (not really sure if this would work). > So I've implemented a simple delegate class for now which: creates a black > window the size of the screen; loads the defaults; finds the screen saver; > adds a ScreenSaverView subview; orders it to front; and calls the > ScreenSaverView's -startAnimation method (in that order). > > My questions: > > 1) I still haven't figured out how I'm going to count how many minutes it's > been since the last even, and much less how to even find out if events have > happened. Does anyone have any ideas on how to do this? GNUstep window only get event when it has the focus. There is a small tool in Etoile called 'Idle', which uses Xwindow extension to check how long users have being idling and post notification, I guess. It may be useful for you. Yen-Ju > > 2) I also have no idea how to figure if, once the screen saver is on, how to > stop if when something happens (mouse move, key stroke, mouse click). I've > looked at the docs for NSView and there doesn't seem to be any methods that > would make this easy. What can I do here? > > 3) Once the preference module is completed and working, I'll need to have > gssaver check the defaults after the preferences change, is there anyway I > can send it a message asking it to check the defaults fromt the preference > module? > > 4) Lastly, I'll need a lot of help creating ScreenSaverDefaults, but only > later. I've check NSUserDefaults' code and I'm more confused now than I was > when I started out. I figured for this, the best thing would be to create a > new file (ScreenSaverDefaults) under the Defaults directory. > NSUserDefaults, however, seems to be very picky about there being a process > running and writing to that process. > > After it's all said and done I'd like to add this to GNUstep as I think it > would make more sense being distributed by it (much like SystemPreferences > and it's NSPreferencePane implementation). I already have a copyright > assignment, so it shouldn't be a problem. > > Any comments and/or suggestions would be appreciated. > > Stefan > > ___ > 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
Support _NET_WM_DESKTOP
This is an unfinished patch for _NET_WM_DESKTOP as a demonstration.
The idea is that when one of the window of an application is moved to
another virtual desktop,
the menu, app icon, floating panel, etc. should also be moved to the
same desktop.
WindowMaker current do that, I think, but it should be done by GNUstep
so that users of all desktop environment can benefit.
This patch only shows how to receive event for _NET_WM_DESKTOP
and retrieve the new desktop.
But I don't know how to get all windows belonging to the same application.
To change desktop of window, just send a client message:
http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2511177
Yen-Ju
Index: Source/x11/XGServerWindow.m
===
--- Source/x11/XGServerWindow.m (revision 25397)
+++ Source/x11/XGServerWindow.m (working copy)
@@ -1897,7 +1897,7 @@
| EnterWindowMask
| LeaveWindowMask
| FocusChangeMask
-//| PropertyChangeMask
+| PropertyChangeMask
//| ColormapChangeMask
| KeymapStateMask
| VisibilityChangeMask
Index: Source/x11/XGServerEvent.m
===
--- Source/x11/XGServerEvent.m (revision 25397)
+++ Source/x11/XGServerEvent.m (working copy)
@@ -1311,6 +1311,36 @@
NSDebugLLog(@"NSEvent", @"%d PropertyNotify - '%s'\n",
xEvent.xproperty.window,
XGetAtomName(dpy, xEvent.xproperty.atom));
+ {
+ Atom XG_NET_WM_DESKTOP = XInternAtom(dpy, "_NET_WM_DESKTOP", False);
+ if (xEvent.xproperty.atom == XG_NET_WM_DESKTOP)
+ {
+// NSLog(@"Change desktop");
+ unsigned long *data = NULL;
+ Atom prop = XInternAtom(dpy, "_NET_WM_DESKTOP", False);
+ Atom type_ret;
+ int format_ret;
+ unsigned long after_ret, count;
+ int result = XGetWindowProperty(dpy, xEvent.xproperty.window, prop,
+ 0, 0x7FFF, False, XA_CARDINAL,
+ &type_ret, &format_ret, &count,
+ &after_ret, (unsigned char **)&data);
+ if ((result != Success))
+ {
+NSLog(@"Error: cannot get _NET_WM_DESKTOP of client");
+if (data)
+{
+ XFree(data);
+ data = NULL;
+}
+break;
+ }
+ int desktop = (int)*data;
+ XFree(data);
+ data = NULL;
+ NSLog(@"New desktop %d", desktop);
+ }
+ }
break;
// a client successfully reparents a window
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Support _NET_WM_DESKTOP
On 8/21/07, Fred Kiefer <[EMAIL PROTECTED]> wrote:
> Thank you for this patch. I am not that sure if we really should apply
> it. There are two reasons against it. First accepting all the property
> changed notifications is an extra burden for the program, currently we
> don't need to know about them (Except for my new code to avoid the style
> test windows). Second I don't really know what to do when we know that
> the desktop has been changed. Your code currently just looks this event
> and you suggest that we should then move all the windows to the new
> desktop. But is this what the user expects? When I move one window to
> another desktop, I want just that window there. When I want all of them
> to move, I apply functionality of my pager to do so.
> Are you using this differently?
This is the situation I try to solve:
A user opens a new document of Ink.app in desktop 1
and decide to move that document to desktop 2
with window manager or any other X program.
Then he realizes the menu and app icon of Ink.app still stay in desktop 1
and he has to move them to desktop 2 one-by-one.
If it is the case of Gorm, then he has a lot of windows to move.
So the ideal case is that if one of the windows belonging to the
same application
is moved to another desktop, menu, app icon and floating panel should follow.
The patch is not completed.
It is just to show how to know when client window changes
desktop by other X program.
Yen-Ju
>
> Fred
>
> Yen-Ju Chen wrote:
> > This is an unfinished patch for _NET_WM_DESKTOP as a demonstration.
> > The idea is that when one of the window of an application is moved to
> > another virtual desktop,
> > the menu, app icon, floating panel, etc. should also be moved to the
> > same desktop.
> > WindowMaker current do that, I think, but it should be done by GNUstep
> > so that users of all desktop environment can benefit.
> >
> > This patch only shows how to receive event for _NET_WM_DESKTOP
> > and retrieve the new desktop.
> > But I don't know how to get all windows belonging to the same application.
> > To change desktop of window, just send a client message:
> > http://standards.freedesktop.org/wm-spec/wm-spec-1.4.html#id2511177
> >
> > Yen-Ju
> >
> >
> >
> >
> > Index: Source/x11/XGServerWindow.m
> > ===
> > --- Source/x11/XGServerWindow.m (revision 25397)
> > +++ Source/x11/XGServerWindow.m (working copy)
> > @@ -1897,7 +1897,7 @@
> > | EnterWindowMask
> > | LeaveWindowMask
> > | FocusChangeMask
> > -//| PropertyChangeMask
> > +| PropertyChangeMask
> > //| ColormapChangeMask
> > | KeymapStateMask
> > | VisibilityChangeMask
> > Index: Source/x11/XGServerEvent.m
> > ===
> > --- Source/x11/XGServerEvent.m(revision 25397)
> > +++ Source/x11/XGServerEvent.m(working copy)
> > @@ -1311,6 +1311,36 @@
> > NSDebugLLog(@"NSEvent", @"%d PropertyNotify - '%s'\n",
> > xEvent.xproperty.window,
> > XGetAtomName(dpy, xEvent.xproperty.atom));
> > + {
> > + Atom XG_NET_WM_DESKTOP = XInternAtom(dpy, "_NET_WM_DESKTOP",
> > False);
> > + if (xEvent.xproperty.atom == XG_NET_WM_DESKTOP)
> > + {
> > +// NSLog(@"Change desktop");
> > + unsigned long *data = NULL;
> > + Atom prop = XInternAtom(dpy, "_NET_WM_DESKTOP",
> > False);
> > + Atom type_ret;
> > + int format_ret;
> > + unsigned long after_ret, count;
> > + int result = XGetWindowProperty(dpy,
> > xEvent.xproperty.window, prop,
> > + 0, 0x7FFF, False, XA_CARDINAL,
> > + &type_ret, &format_ret, &count,
> > + &after_ret, (unsigned char **)&data);
> > + if ((result != Success))
> > + {
> > + NSLog(@"Error: cannot get _NET_WM_DESKTOP of
> > client");
> > + if (data)
> > + {
> > + XFree(data);
> > + data = NU
Patch for GSSocketStream
The recent change on GSSockeStream breaks my application.
I do not have GNU TLS installed, so GSSocketStream uses a dummy version of
GSTLS.
But it does not override the +tryInput:output: and it raises exception.
This is a patch for it.
Yen-Ju
Index: Source/GSSocketStream.m
===
--- Source/GSSocketStream.m (revision 25933)
+++ Source/GSSocketStream.m (working copy)
@@ -560,6 +560,10 @@
DESTROY(self);
return nil;
}
++ (void) tryInput: (GSSocketInputStream*)i output: (GSSocketOutputStream*)o
+{
+}
+
@end
#endif /* HAVE_GNUTLS */
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSOC: desktop integration
On Mon, Mar 24, 2008 at 2:30 AM, Hubert Chathi <[EMAIL PROTECTED]> wrote: > On Sat, 22 Mar 2008 12:57:32 -0800, "Matt Rice" <[EMAIL PROTECTED]> said: > > > On Sat, Mar 22, 2008 at 12:02 PM, Hubert Chathi <[EMAIL PROTECTED]> wrote: > >> Hi all, > >> > >> I'm looking at applying for Google's SOC this year. I'm interested > >> in looking at GNU/Linux desktop integration issues. So I'd like to > >> look at: - the window focusing issues, and making GNUstep work well > >> in all window managers > > > I think this is a good idea, though I am wondering the scope of your > > intent, e.g. to make gnustep usable with sloppy focus, or to fix > > issues with click-to-focus, or both > > > i think these are separate issues so maybe you could elaborate a bit. > > I'm not sure exactly what the issues are, or how much work is involved > in solving them. I just saw the issue listed on the wiki, and I > remember reading some discussion about it on the bugs mailing list. I personally think it is easier to have a window manager which can work well on both GNUstep and GNOME/KDE, or specifically, EWMH. Overall, it is hard to map GNUStep window hints into EWMH. For example, GNUstep requires arbitrary window level while EWMH doesn't. GNUstep may work under EWMH, but it will not work perfectly. I believe the reason people ask for GNUstep to work with GNOME/KDE is that WindowMaker does not work well for GNOME/KDE. If there is a window manager which can work on both GNUstep and GNOME/KDE, this problem can be solved. Yen-Ju [snip] > > -- > Hubert Chathi - Email/Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ > PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) > Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA > > > > > ___ > 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 ... alternative ideas
On 2/19/06, Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: > > On 19 Feb 2006, at 05:27, Andrew Ruder wrote: > [snip] > > Possible setups might be ... > > Linux FHS installation (really just needs implementing in gnustep-make) I guess his point is that someone may just want to compile GNUstep-base as libgnustep-base.so and install it in /usr/local/lib and link it without the whole GNUstep/ directories. In this way, it might be easier to ship something in binary format. If this can be done, a document probably will do. Yen-Ju [snip] > > > > ___ > 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
On 2/22/06, Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: [snip] > > > I'm just trying to find out exactly what your problems are so we can > do something to avoid them ... and it's sounding to me like we just > need an alternative installation script to install stuff in the FHS > locations ... something that's been on the roadmap for gnustep-make > for quite a while now. Maybe a script called 'gnustep-config' can help. People can find the header and library with 'gnustep-config --cflags' and 'gnustep-config --libs'. It is used in many libraries. Yen-Ju > > > > ___ > 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: FHS compliance/Abstraction of NSBundle
Andrew Ruder aeruder.net> writes: > > On Mon, May 08, 2006 at 07:21:04PM -0700, Gregory John Casamento wrote: > > FHS Compliance > > == > > We could have Foundation and AppKit in the /usr/local/include > > directory, the libraries in /usr/local/lib and the resources for the > > libraries in /usr/local/share. This could be offered as an option > > for the user at configuration time. This would allow the deployment > > of GNUstep in an FHS compatible fashion. > > I don't believe that this should be an option; this should be *STANDARD* > operation. As I discussed with Greg earlier, I think one problem with > GNUstep is that there is an incredibly large barrier to entry: [snip] I think it is unfair to say that just because GNUstep does not conform to FHS and has some other features. FHS is not the only choice in open source world. Even Xwindow is installed in difference place in Linux, FreeBSD and MacOS X. I got GNUstep ready to use through DarwinPorts. The only thing I need to learn is to start GNUstep.sh and use 'openapp'. On the other hand, I don't even know how to start Gnome if I start xwindow from terminal (This happens when I crash Gnome and am forced to quit xwindow). What we need is a desktop environment like Gnome and KDE. There are several attempts including Etoile. I remember the time I use gnome 0.x or 1.x. It is just like GNUstep now. What we need is a good installaion system, which can go through the package system in distros, and some good applications and integration. Look at Xfce, which is also a nice dekstop environment. I believe it conforms to FHS (never use it, though). It is still not as popular as Gnome and KDE. But I do think the OpenGroupware.org has a good arguement that Foundation should have an option to be installed in FHS as libFoundation. AppKit need some other resources and is not worth to do that in my own opinions Yen-Ju > > - Andy > > P.S. I think this will also boost our adoption into distros incredibly, > GNUstep is not exactly the easiest thing to get into a distro due to its > non-conformity. > > > One of the things which I've done on the NibCompatibility branch is to > > abstract the model loading mechanism so that it has "loader" classes. > > Each loader handles a specific type of gui model (i.e. GSGormLoader > > for gorms, GSNibLoader for nibs and GSGModelLoader for gmodels). Each > > loader registers itself with a factory class so that the scheme is > > entirely open and can be easily extended. A similar scheme would be > > possible to implement for NSBundles. > > P.P.S. Excellent work on the Nib loading stuff so far. It will be a > great boon to GNUstep. :) > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Re: WildMenus and layering...
On 7/13/06, Adam Fedor <[EMAIL PROTECTED]> wrote: You might look at setting _NET_WM_STRUT_PARTIAL for window managers that support EWMH. Although I think the GNOME panels might do something like set the window type/level, I'm not really sure that's what you want. Either case, you might have to hack the backend and possible define an interface between the front and backend (gui/back) to get it to work transparently from GNUstep. If you use EtoileMenuServer from Etoile project (www.etoie-project.org), the _NET_WM_STRUT_PARTIAL is set. You can get some screenshot here: http://www.etoile-project.org/etoile/blog/ You have to compile EtoileMenuServer with 'make x11=yes' in order to work. It is still experimental, though. Yen-Ju ___ 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: Re: The need for an official GNUstep desktop
Many usable applications are scattering around and most of them are one-man-projects. Below is the list I have in mind. To me, these applications are sufficient to be a nice desktop environment after some polish. I think it will be better to have everything in one place and all developers can peek into each project from time to time. And regarding to the vision of desktop environment, let's have a regular one before an evolutionary one. GWorkspace (http://www.gnustep.it/enrico/gworkspace/) GNUMail (http://www.collaboration-world.com/gnumail) Terminal (http://www.nongnu.org/backbone) Azalea (http://www.etoile-project.org) - window manager EtoileMenuServer (http://www.etoile-project.org) - menu bar Camaelon (http://www.etoile-project.org) - theme engine TalkSoup (http://talksoup.aeruder.net/) - IRC client Grr (http://www.etoile-project.org) - RSS reader Dictionary (http://www.etoile-project.org) Preview (http://home.gna.org/gsimageapps/) - image viewer Vindaloo (http://home.gna.org/gsimageapps/) - PDF viewer Affiche (http://www.collaboration-world.com/affiche), a post-it application Yen-Ju ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Re: Re: The need for an official GNUstep desktop
On 8/27/06, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: Many usable applications are scattering around and most of them are one-man-projects. Below is the list I have in mind. To me, these applications are sufficient to be a nice desktop environment after some polish. I think it will be better to have everything in one place and all developers can peek into each project from time to time. While I think it is a good idea to have applications of a desktop environment in one place, it may not be with GNUstep "core". Here is an argument for similar situation: http://www.rubyinside.com/does-ruby-need-more-opinions-207.html GNUstep is more powerful than a foundation for a desktop environment. Because of the tight relation between GTK/GNOME, Qt/KDE, no one will try to use GTK and Qt to write server applications. ( Well, the argument here is not completely right here since GTK and Qt start as widget toolkit for xwindow. ) If we have a desktop environment with GNUstep "core" in one place, people might think GNUstep is just like GTK/Qt. Having GNUstep "core" and desktop environment in two places is not too bad for users. At least GNUstep won't be shadowed if the desktop environment successes. Yen-Ju ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Re: Advertisement for gnustep
On 9/10/06, Nicola Pero <[EMAIL PROTECTED]> wrote: > > Can we advertise ObjC + GNUstep as a 'truly free' replacement for Java ? > > That would be fun. ;-) > Not really, since you can perfectly develop highly complex multi- > platform GUI apps in Java, whereas this is far from realistic with > GNUstep, I am afraid. Good point ... I'm afraid I was thinking of the "server-side" Java. ;-) I mean, you know all those "enterprise applications" that have no GUI -- or that have a web interface as the user interface. :-) Thanks I would say it is safe to emphasize that GNUstep is a developement environment and mentions projects from both server-side and desktop-side (like Etoile or GWorkspace). I don't think it is necessay to mention the maturity of these projects on FSF web page since it is not going to be update frequently. It is the responsibity of each project to state their current progress. Yen-Ju ___ 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: Problems when resizing window
On 10/3/06, Fred Kiefer <[EMAIL PROTECTED]> wrote:
Even after all the backend window changes I still have problems when
resizing a window. The reported error is:
2006-10-03 15:50:15.860 GSTest[25446] X-Windows error - BadValue
(integer parameter out of range for operation)
on display: :0.0
type: 0
serial number: 669
request code: 143
I have the same problem (request code: 143) relating to the resizing.
I guess it is caused by the calculation of style offset.
But since it is not a critical error, I didn't take a deep look.
Yen-Ju
This is caused by the following stack:
Breakpoint 2, XGErrorHandler (display=0x8189960, err=0xbf9d177c)
at XGServerEvent.m:121
121 XGServer *ctxt = (XGServer*)GSCurrentServer();
(gdb) bt
#0 XGErrorHandler (display=0x8189960, err=0xbf9d177c) at
XGServerEvent.m:121
#1 0xb709027f in _XError () from /usr/X11R6/lib/libX11.so.6
#2 0xb7091f54 in _XReply () from /usr/X11R6/lib/libX11.so.6
#3 0xb707a396 in XGetWindowProperty () from /usr/X11R6/lib/libX11.so.6
#4 0xb71f1442 in PropGetCheckProperty (dpy=0x8189960, window=73400357,
hint=403, type=6, format=32, count=4, retCount=0xbf9d1930)
at XGServerWindow.m:114
#5 0xb71f6e60 in -[XGServer(WindowOps) styleoffsets::] (self=0x81884d8,
_cmd=0xb724def0, l=0xbf9d1988, r=0xbf9d1984, t=0xbf9d1990, b=0xbf9d198c,
style=15, win=73400357) at XGServerWindow.m:2043
#6 0xb71f2165 in -[XGServer(WindowOps) _XFrameToOSFrame:for:] (
self=0x81884d8, _cmd=0xb724d078, x=
{origin = {x = 100, y = 714}, size = {width = 485, height = 114}},
window=0x81f6218) at XGServerWindow.m:494
#7 0xb71ed4bd in -[XGServer(EventOps) processEvent:] (self=0x81884d8,
_cmd=0xb724d018, event=0xbf9d1de0) at XGServerEvent.m:808
#8 0xb71eb828 in -[XGServer(EventOps) receivedEvent:type:extra:forMode:] (
self=0x81884d8, _cmd=0xb7c00958, data=0x7, type=ET_RDESC, extra=0x7,
mode=0xb7bcd918) at XGServerEvent.m:301
#9 0xb7aafc4a in -[GSRunLoopCtxt pollUntil:within:] (self=0x81a40d0,
This happens with the art backend, the xlib and the cairo backend both
resize without an error, which is quite surprising for me. I use KDE
with the default window manager (kwin ?) running under SuSE Linux 10.1.
Yes this is with an updated GNUstep from today.
Cheers
Fred
PS: Why does "openapp ./GSTest" work but for debugging I have to specify
"debugapp ./GSTest.app". Without the file extension gdb complains it
cannot find the program.
___
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
