Hello KaKaRoTo, thank you for your response!
As you said, having a non-modal dialog is better than having a window
freeze or an error popping up to the user. That was my initial
response to the problem at the beginning, to just ignore the error. So
yup I do think what you said would be a perfect solution. Actually,
there really isn't a solution to this problem since it's really a tk
bug. But we have to try to do the best we can to avoid the user
noticing it, and the 5 time retry solution would be best. It has
everything in it, the new solution I proposed, and the initial
response which was to ignore the error and proceed normally. Also,
since this issue is really a tk bug, the best solution would be to
rename the grab function like you said. If I could test that code I
would, but right now im in another country and the internet here is
extremely slow. I can't even login with amsn due to connection
problems. The number of retries is a good precaution, although i think
it will never have to be more than one sicne this issue really happens
due to two applications "racing" to focus the same window and tk can't
handle that. But then after the other application focuses the window,
tk can focus it without any problems. So ya the retry is a very good
precaution incase something does happen.
Anyways so those are my thoughts. What does everyone else think?
On Mon, Jan 19, 2009 at 2:48 AM, Youness Alaoui
<kakar...@kakaroto.homelinux.net> wrote:
> Hello, sorry for the oh-so-late response, I just didn't feel like reading
> the huge thread for a while! anyways, now I got the time, so I've read it,
> quite interesting and now it's time to get my answer on the subject!
>
> ok, so first, nice to see all that info and thanks for the detailed mail and
> the contribution!
> about the grab set error, yes, that's crappy , but it's really rare
> (apparently though you got a reproducable case, yeay), the solution is
> usually to just 'catch' the error.. if there's an error, well too bad, at
> least we don't crash, if the window is not modal, then who cares.. as long
> as we don't raise an error..
> Anyways, the catch solution is usually good enough.. however you seem to be
> coming up with a better solution, I like that.. however, the 'after' is not
> really that good because it will freeze the application (afaik), so if the
> window never becomes catchable, then we would get the amsn window frozen...
> I think having a 5 retries limit would be better, so at most it will freeze
> for 500 ms, not more... which is not noticable.. if we really can't do
> anything about it.. having a non-modal is better than having a window freeze
> ,or having a tk error report window popping up and our code getting screwed
> (since the rest of the function doesn't get called, so stuff might stop
> working...).
> Anyways, the error is because 'window is not focused'.. so how about we do
> something like :
> - grab set $w
> + catch {focus -force $w}
> + catch {grab set $w}
> we might get better chances of it working if we force the focus on the
> window before trying to grab....
> So I think what would be the best solution is to use your latest patch
> (looping and retrying), add a 5 retries limit to it, add a focus -force on
> it.. and that should be the best solution ever...
> however, I don't think that function is the only one calling the 'grab
> set'.. there are a few others and they also cause issues... and we can't all
> modify them, because the worst of it all is that there is some 'grab' calsl
> inside of tk's code that we can't modify.. so a solution would be :
> rename grab ::tk::grab
> proc grab { command window } {
> if {$command != "set" } {
> ::tk::grab $command $window
> } else {
> set retries 5
> while { $retries > 0 } {
> catch {focus -force $window}
> if {[catch {grab set $window}] {
> break
> }
> after 100
> incr retries -1
> }
> }
> }
> (not tested code.. just pseudo-code)
> What does everyone think ?
> KaKaRoTo
> 2009/1/12 PEACEYALL <peacey...@gmail.com>
>>
>> Helloo again!
>>
>> Okie, I think I have found a proper solution that doesn't just conceal
>> the error message. Actually, this solution is taken from a python
>> project called PMW (Python Megawidgets).
>> This is the snippet from the PMW project:
>> ----------
>> while 1:
>> try:
>> if globalMode:
>> widget.grab_set_global()
>> else:
>> widget.grab_set()
>> break
>> except Tkinter.TclError:
>> # Another application has grab. Keep trying until
>> # grab can succeed.
>> self.after(100)
>> ----------
>>
>> Anyways so I have implemented it into gui.tcl and tested it. As
>> expected, no more errors are produced and the chat window is blocked
>> from keyboard/input events until the close dialog closes and returns
>> focus and events to the chat window. Which is what the code intended
>> to do in the beginning. The proposed patch is attached. I hope it's
>> enough to fix the problem!
>>
>>
>> On Mon, Jan 12, 2009 at 1:03 AM, PEACEYALL <peacey...@gmail.com> wrote:
>> > Ooh and btw, that problem of course happens after the second solution
>> > is applied.
>> >
>> > On Mon, Jan 12, 2009 at 12:58 AM, PEACEYALL <peacey...@gmail.com> wrote:
>> >> Hii Tom!
>> >>
>> >> Ya I thought of that too. Although there is one more problem that I
>> >> have seen but it is extremelyhard to replicate so I really don't think
>> >> it's that big of an issue. See, sometimes, if you click one of the
>> >> buttons on the close dialog too fast, as in less than a second and i
>> >> really mean less than a second, a tk error dialog will pop up with the
>> >> following in the detail:
>> >> "can't read "customMessageBoxAnswerTracker(ContainerClose)": no such
>> >> element in array
>> >> while executing
>> >> "list $customMessageBoxAnswerTracker($uniqueId)
>> >> $customMessageBoxRememberTracker($uniqueId)"
>> >> (procedure "::amsn::customMessageBox" line 117)
>> >> invoked from within
>> >> "::amsn::customMessageBox [trans closeall] yesnocancel question [trans
>> >> title] $window 1 1 "ContainerClose""
>> >> (procedure "::ChatWindow::ContainerClose" line 18)
>> >> invoked from within
>> >> "::ChatWindow::ContainerClose .container_14"
>> >> (command for "WM_DELETE_WINDOW" window manager protocol)"
>> >>
>> >> Again, this hardly ever happens since I really don't think anyone is
>> >> going to click one of the buttons on the close dialog in less than a
>> >> second of it opening. Though, even when it does happen, it doesn't
>> >> affect any functionality since the buttons and the whole dialog itself
>> >> still works as expected and doesn't casue any visible problems, at
>> >> leats none that I have found.
>> >> Anyways, I think it would be safe to commit overall :D
>> >>
>> >> On Mon, Jan 12, 2009 at 12:46 AM, Tom Hennigan <tomhenni...@gmail.com>
>> >> wrote:
>> >>> Hey man thanks for your in depth description of the issue!
>> >>>
>> >>> I think that the second solution is better. The customMessageBox is
>> >>> used
>> >>> in other places throughout aMSN's code base as well, and the modal
>> >>> behavior may be necessary there.
>> >>>
>> >>> If no-one has any better solutions I will commit this?
>> >>>
>> >>> - Tom
>> >>>
>> >>> PEACEYALL wrote:
>> >>>> Hello!
>> >>>>
>> >>>> This is my first time programming tcl so I barely know anything about
>> >>>> how dialog boxes work in tk. Anyways, If I try to close the chat
>> >>>> window while more than one tab is opened from the compiz-fusion scale
>> >>>> addon (as in the expose mac os x-like feature in compiz-fusion),
>> >>>> after
>> >>>> the close dialog appears, an empty tk error dialog also appears with
>> >>>> the following text as detail:
>> >>>> "grab failed: another application has grab
>> >>>> while executing
>> >>>> "grab set $w"
>> >>>> (procedure "::amsn::customMessageBox" line 106)
>> >>>> invoked from within
>> >>>> "::amsn::customMessageBox [trans closeall] yesnocancel question
>> >>>> [trans
>> >>>> title] $window 1 1 "ContainerClose""
>> >>>> (procedure "::ChatWindow::ContainerClose" line 18)
>> >>>> invoked from within
>> >>>> "::ChatWindow::ContainerClose .container_0"
>> >>>> (command for "WM_DELETE_WINDOW" window manager protocol)"
>> >>>> When that error dialog appears, the buttons on the close dialog no
>> >>>> longer work and the only way I can close the chat window is to close
>> >>>> each tab seperately until all the tabs have closed. In addition, now
>> >>>> the close dialog that has appeared before isn't receiving any input
>> >>>> and the only way to close it is to restart amsn or press the "esc"
>> >>>> key
>> >>>> while the close dialog is focused.
>> >>>>
>> >>>> Since I know nothing of tk, I can only think of two solutions which
>> >>>> are:
>> >>>>
>> >>>> 1. Create the clos
>> \e customMessageBox as a non-modal dialog. (Since I
>> >>>> don't think creating it as a modal dialog is that necessary on
>> >>>> account that it would be perfectly fine if all events are still
>> >>>> available in the chat window while the dialog appears in my opinion)
>> >>>>
>> >>>> 2. In the function ::amsn::customMessageBox on line 835, add a catch
>> >>>> statement around "grab set $w"
>> >>>>
>> >>>> Actually both those solutions aren't actually solutions, they're just
>> >>>> workarounds.
>> >>>> The first one doesn't even run the grab statement anymore since the
>> >>>> if
>> >>>> block it's in wouldn't be run.
>> >>>> The second one is a workaround since even though the tk error messgae
>> >>>> dialog isn't displayed anymore and everything seems to continue as
>> >>>> normal (i.e.: All the buttons on the dialog work as they're supposed
>> >>>> to), the chat window still allows events/inputs and therefore the
>> >>>> dialog isn't actually a "real" modal dialog anymore. Honestly, I
>> >>>> can't
>> >>>> evaluate which would be the better solution for the reason that
>> >>>> they're both just quick workarounds. Though, I think the second one
>> >>>> would be better because in this case, the only drawback is that even
>> >>>> though the close dialog will stay a modal dialog, when an error like
>> >>>> this should have appeared, it would suppress it and the chat window
>> >>>> would still be able to receive events, but as stated before, the
>> >>>> close
>> >>>> dialog actually does receive input and work as the user expects in
>> >>>> comparison to if the error was not suppressed.
>> >>>>
>> >>>> Anyways, for the second workaround, I have proposed the patch for it
>> >>>> if someone wants to test it.
>> >>>>
>> >>>> Again, I am pretty much illiterate in Tk, so if someone has a better
>> >>>> idea or has a proper solution, please say it.
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------------------------------------------------------------------
>> >>>>
>> >>>>
>> >>>> ------------------------------------------------------------------------------
>> >>>> Check out the new SourceForge.net Marketplace.
>> >>>> It is the best place to buy or sell services for
>> >>>> just about anything Open Source.
>> >>>> http://p.sf.net/sfu/Xq1LFB
>> >>>>
>> >>>>
>> >>>>
>> >>>> ------------------------------------------------------------------------
>> >>>>
>> >>>> _______________________________________________
>> >>>> Amsn-devel mailing list
>> >>>> Amsn-devel@lists.sourceforge.net
>> >>>> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> Check out the new SourceForge.net Marketplace.
>> >>> It is the best place to buy or sell services for
>> >>> just about anything Open Source.
>> >>> http://p.sf.net/sfu/Xq1LFB
>> >>> _______________________________________________
>> >>> Amsn-devel mailing list
>> >>> Amsn-devel@lists.sourceforge.net
>> >>> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>> >>>
>> >>
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________
>> Amsn-devel mailing list
>> Amsn-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Amsn-devel mailing list
> Amsn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/amsn-devel
>
>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Amsn-devel mailing list
Amsn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/amsn-devel
