[Pharo-project] potential bugfix for orphan OCompletion menus
Dear list, I just published a version of OCompletion with a possible fix for the bug in which OCompletion menus would stay on the screen after a browser is closed. The issue here is inherited from eCompletion: the menu morph is not a child of the window, but a top-level morph. To adress this, I implemented a timeout mechanism: if their was no keystroke in the editor which spawned the menu for the last 5 seconds, the menu will close automatically. You can hence try Ocompletion-RomainRobbes.54 on squeaksource, and tell me what you think of the solution, or of the length of the timeout (I tried to stay conservative, maybe something like 3 seconds would work better). Cheers, Romain -- Romain Robbes http://romain.robb.es rrobbes@dcc.uchile.cl
On Apr 8, 2010, at 7:51 PM, Romain Robbes wrote:
Dear list,
I just published a version of OCompletion with a possible fix for the bug in which OCompletion menus would stay on the screen after a browser is closed.
Excellent!
The issue here is inherited from eCompletion: the menu morph is not a child of the window, but a top-level morph. To adress this, I implemented a timeout mechanism: if their was no keystroke in the editor which spawned the menu for the last 5 seconds, the menu will close automatically.
You can hence try Ocompletion-RomainRobbes.54 on squeaksource, and tell me what you think of the solution, or of the length of the timeout (I tried to stay conservative, maybe something like 3 seconds would work better).
I'm sure that people will give you feedback.
Cheers, Romain
-- Romain Robbes http://romain.robb.es rrobbes@dcc.uchile.cl
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I also published, in Ocompletion-RomainRobbes.55, a potential fix for this issue: http://code.google.com/p/pharo/issues/detail?id=1678 Cheers, Romain On Apr 8, 2010, at 4:55 PM, Stéphane Ducasse wrote:
On Apr 8, 2010, at 7:51 PM, Romain Robbes wrote:
Dear list,
I just published a version of OCompletion with a possible fix for the bug in which OCompletion menus would stay on the screen after a browser is closed.
Excellent!
The issue here is inherited from eCompletion: the menu morph is not a child of the window, but a top-level morph. To adress this, I implemented a timeout mechanism: if their was no keystroke in the editor which spawned the menu for the last 5 seconds, the menu will close automatically.
You can hence try Ocompletion-RomainRobbes.54 on squeaksource, and tell me what you think of the solution, or of the length of the timeout (I tried to stay conservative, maybe something like 3 seconds would work better).
I'm sure that people will give you feedback.
Cheers, Romain
-- Romain Robbes http://romain.robb.es rrobbes@dcc.uchile.cl
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://romain.robb.es rrobbes@dcc.uchile.cl
great this one was annoying too :) On Apr 8, 2010, at 11:16 PM, Romain Robbes wrote:
I also published, in Ocompletion-RomainRobbes.55, a potential fix for this issue:
http://code.google.com/p/pharo/issues/detail?id=1678
Cheers, Romain
On Apr 8, 2010, at 4:55 PM, Stéphane Ducasse wrote:
On Apr 8, 2010, at 7:51 PM, Romain Robbes wrote:
Dear list,
I just published a version of OCompletion with a possible fix for the bug in which OCompletion menus would stay on the screen after a browser is closed.
Excellent!
The issue here is inherited from eCompletion: the menu morph is not a child of the window, but a top-level morph. To adress this, I implemented a timeout mechanism: if their was no keystroke in the editor which spawned the menu for the last 5 seconds, the menu will close automatically.
You can hence try Ocompletion-RomainRobbes.54 on squeaksource, and tell me what you think of the solution, or of the length of the timeout (I tried to stay conservative, maybe something like 3 seconds would work better).
I'm sure that people will give you feedback.
Cheers, Romain
-- Romain Robbes http://romain.robb.es rrobbes@dcc.uchile.cl
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://romain.robb.es rrobbes@dcc.uchile.cl
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Thu, Apr 8, 2010 at 7:51 PM, Romain Robbes <romain.robbes@gmail.com>wrote:
Dear list,
I just published a version of OCompletion with a possible fix for the bug in which OCompletion menus would stay on the screen after a browser is closed.
The issue here is inherited from eCompletion: the menu morph is not a child of the window, but a top-level morph. To adress this, I implemented a timeout mechanism: if their was no keystroke in the editor which spawned the menu for the last 5 seconds, the menu will close automatically.
Thanks, this bug was really annoying :) Now...I ask completely for ignorance...why you need to wait a timeout ? there is no way to notify from the browser to the oCompletion popup ? so that when it is close, it notifies the rest...
You can hence try Ocompletion-RomainRobbes.54 on squeaksource, and tell me what you think of the solution, or of the length of the timeout (I tried to stay conservative, maybe something like 3 seconds would work better).
Cheers, Romain
-- Romain Robbes http://romain.robb.es rrobbes@dcc.uchile.cl
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Mariano, I couldn't find a better way. The model has to be notified that the system window closes, and so far I haven't found where that is done (if at all). Of course, I'll be glad to be enlightened on that issue :-). Cheers, Romain On Apr 9, 2010, at 6:49 PM, Mariano Martinez Peck wrote:
On Thu, Apr 8, 2010 at 7:51 PM, Romain Robbes <romain.robbes@gmail.com> wrote: Dear list,
I just published a version of OCompletion with a possible fix for the bug in which OCompletion menus would stay on the screen after a browser is closed.
The issue here is inherited from eCompletion: the menu morph is not a child of the window, but a top-level morph. To adress this, I implemented a timeout mechanism: if their was no keystroke in the editor which spawned the menu for the last 5 seconds, the menu will close automatically.
Thanks, this bug was really annoying :) Now...I ask completely for ignorance...why you need to wait a timeout ? there is no way to notify from the browser to the oCompletion popup ? so that when it is close, it notifies the rest...
You can hence try Ocompletion-RomainRobbes.54 on squeaksource, and tell me what you think of the solution, or of the length of the timeout (I tried to stay conservative, maybe something like 3 seconds would work better).
Cheers, Romain
-- Romain Robbes http://romain.robb.es rrobbes@dcc.uchile.cl
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://romain.robb.es rrobbes@dcc.uchile.cl
On 10.04.2010 01:35, Romain Robbes wrote:
Hi Mariano,
I couldn't find a better way. The model has to be notified that the system window closes, and so far I haven't found where that is done (if at all). Of course, I'll be glad to be enlightened on that issue :-).
Cheers, Romain
With the Window Announcements Alexandre made, you could. Those are not in core yet, though, and the fix would not work elsewhere. (Found in Morphic package in PharoTaskForces on squeaksource) You'd probably want support for weak announcements/variable annoucement args first as well, as unsubscribing whenever an OCompletion morph is closed would be somewhat of an exercise otherwise. Cheers, Henry
On 10.04.2010 01:46, Henrik Sperre Johansen wrote:
You'd probably want support for weak announcements/variable annoucement args first as well, as unsubscribing whenever an OCompletion morph is closed would be somewhat of an exercise otherwise.
Cheers, Henry
Err, too many beers... Not much sense in unsubscribing as a result of a window close announcements, the announcer would be gone in a short while anyways :)
Thanks! So that would be for the Pharo 1.1 version, I suppose? Romain On Apr 9, 2010, at 7:46 PM, Henrik Sperre Johansen wrote:
On 10.04.2010 01:35, Romain Robbes wrote:
Hi Mariano,
I couldn't find a better way. The model has to be notified that the system window closes, and so far I haven't found where that is done (if at all). Of course, I'll be glad to be enlightened on that issue :-).
Cheers, Romain
With the Window Announcements Alexandre made, you could. Those are not in core yet, though, and the fix would not work elsewhere. (Found in Morphic package in PharoTaskForces on squeaksource) You'd probably want support for weak announcements/variable annoucement args first as well, as unsubscribing whenever an OCompletion morph is closed would be somewhat of an exercise otherwise.
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://romain.robb.es rrobbes@dcc.uchile.cl
Yes, the window announcements are in 1.1 Alexandre On 9 Apr 2010, at 19:51, Romain Robbes wrote:
Thanks!
So that would be for the Pharo 1.1 version, I suppose?
Romain
On Apr 9, 2010, at 7:46 PM, Henrik Sperre Johansen wrote:
On 10.04.2010 01:35, Romain Robbes wrote:
Hi Mariano,
I couldn't find a better way. The model has to be notified that the system window closes, and so far I haven't found where that is done (if at all). Of course, I'll be glad to be enlightened on that issue :-).
Cheers, Romain
With the Window Announcements Alexandre made, you could. Those are not in core yet, though, and the fix would not work elsewhere. (Found in Morphic package in PharoTaskForces on squeaksource) You'd probably want support for weak announcements/variable annoucement args first as well, as unsubscribing whenever an OCompletion morph is closed would be somewhat of an exercise otherwise.
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Romain Robbes http://romain.robb.es rrobbes@dcc.uchile.cl
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Thanks!
So that would be for the Pharo 1.1 version, I suppose?
Romain Hopefully, yes :) Personally I find it the most annoying things in rc4 to be: 1 it doesn't close immediately when a) I mouseclick another location in the text (only when I type something) b) change focus to another window 2 It does not update the list location when a) I've mouse-clicked another place in the morph and started typing again. b) I've moved/resized the editor
On 10.04.2010 01:51, Romain Robbes wrote: 3) It takes ~ 0.5 -1 second to update if I press down, and on each character typed thereafter with items still in list (Te - down - s - t, s and t take some time to input) 4) Mouse-click on a list item does not select it. 1 is somewhat remedied by the patch I guess, for the rest I guess 2 and 4 should solvable by additional logic, and 3 would require some profiling. 1b and 2a in combination is quite annoying, as the list will be below the morph when you refocus, and in many cases you will be able to see suggestions for the new location. (1/2 b would also be easy to solve with window announcements) In essence, I feel it still could use some improvement with regards to awareness of mouse activity and multiple editors. Cheers, Henry
I was about to say this. Alexandre On 9 Apr 2010, at 19:46, Henrik Sperre Johansen wrote:
On 10.04.2010 01:35, Romain Robbes wrote:
Hi Mariano,
I couldn't find a better way. The model has to be notified that the system window closes, and so far I haven't found where that is done (if at all). Of course, I'll be glad to be enlightened on that issue :-).
Cheers, Romain
With the Window Announcements Alexandre made, you could. Those are not in core yet, though, and the fix would not work elsewhere. (Found in Morphic package in PharoTaskForces on squeaksource) You'd probably want support for weak announcements/variable annoucement args first as well, as unsubscribing whenever an OCompletion morph is closed would be somewhat of an exercise otherwise.
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (5)
-
Alexandre Bergel -
Henrik Sperre Johansen -
Mariano Martinez Peck -
Romain Robbes -
Stéphane Ducasse