Both System and AZDock are now working well on my machine. Distributed notifications are fixed in GNUstep base trunk (r27154) and I improved System (r4205) to be able to carry out the launch sequence even if they don't work.
I hope it's really fixed now :-) You just need to be careful when updating GNUstep base… here is the copy of a mail I posted to gnustep-discuss list about the issue: > If you compile GNUstep from source, I just want let you know that > GNUstep base from trunk is now installed in Local domain rather than > System domain. > So if you build and install GNUstep base above r27148, you should > run 'make uninstall' before updating to the new revision. If you > don't, the old library and tools installed in System will continue > to be used rather than the new one installed in Local. I just > stumbled on this problem before realizing the installation domain > has changed, that's why I'm mentionning it here. > > I suppose GNUstep GUI, Back and other applications will soon have > their default installation domains altered in the same way. The > change has been discussed on this list and gnustep-dev at the end of > October. > > So don't forget to check where things are installed if a build/ > install seems to have no effect ;-) Quentin. Le 27 nov. 08 à 00:58, Quentin Mathé a écrit : > After further investigations, I found the problem is twofold. > The first bug introduced around r27100 is now fixed in GNUstep > trunk. The bug was causing the following assertion: > >> 2008-11-21 17:42:39.800 etoile_system[6741] cifframe.m:785 Assertion >> failed in cifframe_do_call. Invalid parameter not satisfying: >> GSSelectorTypesMatch(encoded_types, type) > > There is a second issue, that is older than the first one (older > than r27000). NSWorkspace notifications seem to be broken. This > prevents both System and AZDock to work correctly. I filled a bug > report in GNUstep bug tracker. > > In the meantime, I'll commit tomorrow some System improvements to > make it simpler and less prone to similar failures. The launch > sequence now doesn't block when distributed notifications cannot be > used or are not received as expected. With GNUstep trunk (r27135), > Étoilé session starts fine with my local version of System > However the environment remains broken. AZDock don't react to > applications launches or terminations. System is also unable to > track applications that get launched, which means the session cannot > be cleanly closed. > I'll let you know when the issue is fully solved in GNUstep and > Étoilé. > > btw if anybody is successfully using distributed notifications or > NSWorkspace notifications with current GNUstep trunk, I'd be curious > to hear more about it. > > Cheers, > Quentin. > > Le 24 nov. 08 à 15:30, Fred Morcos a écrit : > >> nothing changed.. still the same. _______________________________________________ Etoile-discuss mailing list [email protected] https://mail.gna.org/listinfo/etoile-discuss
