discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GORM and NSCollectionView


From: Alessandro Sangiuliano
Subject: Re: GORM and NSCollectionView
Date: Tue, 24 Mar 2015 12:17:49 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0

It is working here too, I'm testing it from yesterday.
I still not reported because I have a problem with the EtoileBehavior bundle after the -back upgrade, I'm trying to fix it. I fixed some of its common problems in the past, like the right click mouseDown; before the fix if you did righ click, the popup menu was shown until you did release the right button of the mouse. This means that to use the popup menus you had to stay with the right button clickend until the operation was ended, releasing the button on the menu items of your choice. This is now fixed, and it works in a normal way.

However this is not a GNUstep problem, and apart the disgression, without the EtoileBehavior bundle, the fix you made is working also in the machintosh menu style.

I'll test on FreeBSD 10.1 later.

Il 24/03/2015 01:54, Philippe Roussel ha scritto:
Hi Fred,

On Sun, Mar 22, 2015 at 04:09:46PM +0100, Fred Kiefer wrote:

[snip]

Now the flickering is gone for me. I still have the other problem of
corrupted subview display after extensive resize, but I wont be looking
into that today. I just will commit my changes and you all should try to
test them with different conditions, maybe even the OpenGL?
Things seems to work nicely on a local display (with the cairo
backend) but are not a lot better on a remote display over ssh. Try
resizing Gemas versus gedit for example, with a WM configured to
redraw the whole window when resizing. GNUstep applications are really
slow, as if way to many events were handled. Let me know if I can be
of any help to track this down if you think it's worth investigating.

Thanks,
Philippe

Coming back on the EtoileBeahvior disgression, can be this the reason of the #if 1 disabling the #else block you rehabilitated with the commits? I mean, there was a similar problem somewhere in GNUstep, that EtoileBehavior bundle shown after -back upgrade, that made Richard to think about disabling the #else block?

Thanks,
Alex



reply via email to

[Prev in Thread] Current Thread [Next in Thread]