Re: Once again the NSOutlineView
Gregory, On 2004-02-17 03:53:41 +0100 Gregory John Casamento [EMAIL PROTECTED] wrote: [snip] a part of my patch is missing, and I wonder why. At the end of the reloadItem... method I updated _items and _levelOfItems to ensure that those containers reflect the possible change of the item object. Did you just forget this or was something wrong with that part of the patch? What was the change? See the attached patch. It contains what is missing. Basically. the code updates the _items and _levelOfItems lists. The thought was, that if in reloadItem the outline view gets another item object both data structures currently still hold references to the old one. I am actually not quite sure whether it is ok and does not break anything else, but here it seems to work so far. You better check that :-) I did forget about that, or rather, I didn't even realize that there was more in the patch. Sorry for that. As I am currently away from home it will take some time until I am able to correct this. Perhaps somebody else will pick up this task? I will. Thanks. Cheers Andreas -- Andreas Heppel Mail: aheppel at web dot de Home: http://www.andreasheppel.de Check out Burn.app - the CD burning frontend for GNUstep http://gsburn.sourceforge.net ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Once again the NSOutlineView
On 2004-02-18 04:25:58 +0100 Gregory John Casamento [EMAIL PROTECTED] wrote: I don't seem to have received the patch. You din't. I forgot to attach it :-) NSOutlineViewRemainder.diff -- Andreas Heppel Mail: aheppel at web dot de Home: http://www.andreasheppel.de Check out Burn.app - the CD burning frontend for GNUstep http://gsburn.sourceforge.net NSOutlineViewRemainder.diff Description: Binary data ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Once again the NSOutlineView
Gregory, On 2004-02-15 00:35:23 +0100 Gregory John Casamento [EMAIL PROTECTED] wrote: [snip] Perhaps you may want to take over the maintainance this class? If there is noone else to do it right now, I will, yes. In particular as it seems like I was the only app developer who is intensely using this class (or say, who is trying to get most outof it :-) But be aware that I probably do not understand this code much better than you ;-) I wrote NSOutlineView, so please, if you have any questions about why something was done in a particular way, please let me know. I use this class heavily in Gorm. It was, in fact, originally implemented by me so that we could have an outline based view of the class hierarchy in Gorm. That's good to know. Maybe I am going to bother you with some questions later :-) But seriously, I can do it and maybe I should also take some care of NSTableView as NSOutlineView's ancestor. I've come across some strange stuff here too, but didn't dig into it, yet. BTW, who is the originator of those classes? Maybe he can be of some help for understanding the code. Fabien worked on NSTableView mainly, he and I cooperated when I wrote NSOutlineView to make the code more efficient. There is a lot of complex code in both of these classes, so change them with care. My original intent was to get NSOutlineView working for my purposes, in particular dnd and some reloading issues. Of course, I tried (and with possible further changes will try) to not break any existing code. Concerning the maintenance of those classes (or NSOutlineView in particular) I am quite indifferent. If there is need for a maintainer I can do it, if there is already one, I don't see a reason for a change. I think, we only have to agree on who is going to responsible for this. Cheers, Andreas -- Andreas Heppel Mail: aheppel at web dot de Home: http://www.andreasheppel.de Check out Burn.app - the CD burning frontend for GNUstep http://gsburn.sourceforge.net ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Once again the NSOutlineView
Hi Fred, On 2004-02-14 14:11:51 +0100 Fred Kiefer [EMAIL PROTECTED] wrote: I did (hopefully) resolve this problem in a different way, by removing the helper method and inlining the code into reloadItem:reloadChildren:. This allowed for a few more corrections/simplifications (and would allow for more, if I only would understand better, what this method should do). I must admit, that NSOutlineView is a part of GUI, where I don't understand most of the code. No idea, for example, why it replaces the item with NULL, if it is nil. I just had a look at what you checked in two days ago. Seems ok to me, but a part of my patch is missing, and I wonder why. At the end of the reloadItem... method I updated _items and _levelOfItems to ensure that those containers reflect the possible change of the item object. Did you just forget this or was something wrong with that part of the patch? Otherwise, thanks a lot for checking this in. Andreas -- Andreas Heppel Mail: aheppel at web dot de Home: http://www.andreasheppel.de Check out Burn.app - the CD burning frontend for GNUstep http://gsburn.sourceforge.net ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Once again the NSOutlineView
On 2004-02-14 14:11:51 +0100 Fred Kiefer [EMAIL PROTECTED] wrote: [snip] I did (hopefully) resolve this problem in a different way, by removing the helper method and inlining the code into reloadItem:reloadChildren:. This allowed for a few more corrections/simplifications (and would allow for more, if I only would understand better, what this method should do). I must admit, that NSOutlineView is a part of GUI, where I don't understand most of the code. No idea, for example, why it replaces the item with NULL, if it is nil. Perhaps you may want to take over the maintainance this class? If there is noone else to do it right now, I will, yes. In particular as it seems like I was the only app developer who is intensely using this class (or say, who is trying to get most outof it :-) But be aware that I probably do not understand this code much better than you ;-) But seriously, I can do it and maybe I should also take some care of NSTableView as NSOutlineView's ancestor. I've come across some strange stuff here too, but didn't dig into it, yet. BTW, who is the originator of those classes? Maybe he can be of some help for understanding the code. Cheers, Andreas ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Once again the NSOutlineView
Hi list, I have again stumbled across some strange behaviour in NSOutlineView. This time it has to do with reloading items. The method -reloadItem:reloadChildren is using another method called _findItem:childIndex:ofParent:. I suppose that this method is intended to return the parent and the index relative to this parent of the given item. Unfortunately, it is not, as the parameter 'parent' is not by reference. Furthermore, -reloadItem:reloadChildren does not update NSOutlineView's data structures _items and _levelOfItems, which leads to some more starnge behaviour in the case that the NSOutlineView's delegate does not simply return a changed item, but a new one. Maybe, this behaviour is intended, as the delegate is supposed to return the same, but changed item. However, fixing this is not difficult imho, thus, I'd prefer to change this behaviour. Attached is patch with a fix, containg a couple of detailed comments on what I did. Please anyone comment on this. Thanks. Andreas NSOutlineView.diff -- Andreas Heppel Mail: aheppel at web dot de Home: http://www.andreasheppel.de Check out Burn.app - the CD burning frontend for GNUstep http://gsburn.sourceforge.net NSOutlineView.diff Description: Binary data ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Bug in NSOutlineView's -draggingUpdated ?
Hi list, In it's method -draggingUpdated NSOutlineView calls it's delegate's method -outlineView:validateDrop:... (if the delegate impements this method, this means). According to the doc, this method is meant to validate an ongoing drag action _and_ return an appropriate NSDragOperation value. Unfortunately, -draggingUpdated never evaluates this return value, but always returns NSDragOperationCopy to the system, thus not allowing for appropriate visual feedback. I consider this a bug, which should be easy to fix (if I don't oversee something, this means ;-) The attached patch proposes a simple solution. I am also not too sure about NSTableView. Here, the return value of tableView:validateDrop:... is saved in a variable, but this is also not used as a return value for -draggingUpdated. What is even worse here (at least it seems so to me), is the fact that the validateDrop method is called only in few cases (when the current drag operation is different from the previous one). As I am not sure how this code was actually meant to work, I don't have a proposal. Maybe it's sufficient to simply call this method unconditionally and use its return value as in NSOutlineView. Cheers, Andreas -- SYSGO AG Am Pfaffenstein 14 55270 Klein-Winternheim, Germany Voice: +49-6136-9948-0 Fax: +49-6136-9948-10 Web: www.sysgo.com NSOutlineView.diff NSOutlineView.diff Description: Binary data ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: problem with gpbs
Hi again, rereading my mail from tonight the startup sequence seems to be not too clear. Must have been very sleepy :-) At the moment I start all three servers in the order gdomap - gdnc - gpbs right after the display manager (wdm). On the boot screen I can see the output from the various scripts, and see at least the beginning of my gnustep start script appearing _before_ switching to graphics mode. Could it be that gpbs is up and running way before X comes up, and that gpbs depends strongly on X? This might explain the behaviour. Cheers, Andreas On Tue, 23 Jul 2002 00:28:53 +0200 AndreasHeppel [EMAIL PROTECTED] wrote: Hi Nicola and all the others, I installed version 0.7.8 of gui and back and my system is still working :-) Unfortunately, it did not solve the gpbs problem. Thus, I started to dig around and here is what I found out so far. It seems that gpbs crashes during the pasteboard operation. The (remote) client then hangs in the RPC and is stuck. This happens if and only if I start gpbs during boot time (FYI, I use a suse 7.3 distro and hacked gnustep into suse's set of start/stop scripts.). If I do it manually from a command line everything is fine. Also, if I don't start it at all and let the client application do the work everything goes fine. I tested the thing using GNUMail.app (1.0.2). I open the preferences panel and highlight the user name using the mouse. That's all I need to reproduce this behaviour. A couple of NSLog brought me finally near the place. It is somewhere in 'declareTypes' in the NSPasteboardObject class of gpbs. I am absolutely positive that the call goes out from NSPasteboard and reaches gpbs. Somewhere in there gpbs crashes. The last idea I had was that it might have to do with X. In particular the starting order seems to be important. If I start gpbs after X is up and running I am fine. If I do it during start up of the system (somewhere near the start of X) it goes wrong. How far and how tight are X and gpbs connected? is it possible that some data structures are not initialised properly if gpbs is started to soon after X? At the moment I am too tired to dig deeper into the thing. The other problem is that if start gpbs the erroneous way I have no tty attached to gpbs where I could NSLog what is going on. Where do the logs go in this case? Or any other idea how to debug this? Thanks for your time. Thanks for yours :-) Have a good night. I will. Andreas ___ Discuss-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/discuss-gnustep ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: problem with gpbs
On Tue, 23 Jul 2002 08:21:54 -0600 AdamFedor [EMAIL PROTECTED] wrote: gpbs is very dependant on X. In fact it doesn't really handle things well when it is started before X. I'm not sure how to fix that. Perhaps it would be best if it just aborted/exited if X is not running. That's a clear word. I will then go on and make sure that gpbs starts definitely after X and will be contend with this. Saves me some debugging work :-) Ah, one more question. Do I need to properly close any of the three servers before shutting down the system or will I be fine if I leave them running and have Linux send them a SIGTERM on shutdown? Thanks very much for your help. ANdreas ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: problem with gpbs
Right, it's actually not an answer. Does gpbs have anything to do with gui and back or is it just the combination of the components that might matter? If I find the time tonight I will try and let you know. Andreas BTW, do I have to uninstall xgps before I install back or does back cleanly replace xgps? On Mon, 22 Jul 2002 15:12:33 +0100 (BST) NicolaPero [EMAIL PROTECTED] wrote: Hi there, I have a problem concerning gpbs. I am running a start script launching the GNUstep servers gdomap, gdnc, and gpbs. If I check right after system start all three are running. The problem now is that the first GNUstep app which needs the gpbs tells me that it cannot connect to the server and will start it. Afterwards the app hangs and must be killed. Checking with ps I see that the former instance of gpbs is gone (died? crashed?). Starting the very same app the next time and trying the same everything works fine. The gpbs is started and everything is ok. Any ideas? Maybe solutions? My GNUstep env: gnustep-base 1.3.4 gnustep-gui 0.7.6 gnustep-xgps 0.7.6 gnustep-make 1.3.4 gnustep-objc 1.2.2. I know it's not an answer, but can you try with the latest available release ? gnustep-base 1.3.4 gnustep-gui 0.7.8 gnustep-back 0.7.8 gnustep-make 1.3.4 If you still get the problem, please post again to let us know. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
