From: Lucas H. <lu...@di...> - 2004-10-23 17:00:28
|
The headers were wrong on this email when I replied: Begin forwarded message: Date: Sun, 24 Oct 2004 00:05:30 +1000 From: Lucas Hazel <lu...@di...> To: Tristan Mc Leay <the...@gm...> Subject: Re: [rox-devel] Unhappiness w/OroboROX + ROX-Get On Sat, 23 Oct 2004 22:41:22 +1000 Tristan Mc Leay <the...@gm...> wrote: > Sorry if this is known, but if you download a file with ROX-Get-003, > it hangs up OroboROX. Or maybe more than just that. But while the file > is downloading and the ROX-Get title is changing at a million times a > second, OroboROX refuses to redraw anything, refocus any windows, and > mouse clicks don't get through. (Ctrl-Alt-F1 works, though, and my > gkrellm window keeps updating.) > > Normally when I do this, I'm moving straight from ROX-Get to Archive, > but it takes quite some time before the first dialog disappears and > the second turns up, during which time the system seems to be > remembering mouse clicks and will deal with them later, but it waits > for a while... > > I imagine that the source of this is that OroboROX gets distracted > trying to change the titlebar so frequently. While it might be bad > manners on ROX-Get's part, I think maybe OroboROX should be more > robust here? > > Sorry I can't say anything more at this stage, I have a too many > assignments due this week... > Sorry my bad, I will look into a better way for monitoring progress for the next release of ROXget, the current method is to send a callback after segment of data is recieved. It is a shame that oroborox can't keep up, but you're probably right, it is a bit rude of me to be changing the title so often. I do intend to have a future version with a seperate status window. But I would like the main window to have some sort of progress reporting. Initially, I have 2 ideas: 1. Make the title change less frequently. 2. Add a progress bar widget to the main window. A temporary fix would be to turn off the callback: line 53 of ROXget.py: self.result = self.download.write(stream,self.update_status) change it to: self.result = self.download.write(stream) And that will disable the percentage reporting. What do the oroborox devs have to say on the matter? -- Lucas Hazel <lu...@di...> Student, BSDfreak University of New England (http://cs.une.edu.au) Armidale, Australia [http://www.digitillogic.net] ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." (Mark Twain) ================================================= |
From: Guido S. <__g...@we...> - 2004-10-23 21:24:30
|
Am 23.10.2004 18:59:41 schrieb(en) Lucas Hazel: > And that will disable the percentage reporting. What do the oroborox > devs have to say on the matter? Application bug, plain and simple. OroboROX only does what it is told. What if it was a status bar instead you were drawing on? Then the wm couldn't do anything. Or when ROXget runs on win32 (might work), where window decoration is drawn by the application (toolkit). What I could do is checking if NET_WM_NAME actually changed when OroboROX receives a NET_WM_NAME client message. That would be acceptable. Setting an upper bound for refreshs would be more involved. I think that's not the job of the window manager to decide. Such heavy polling as ROXget does, will still waste lots of CPU anyway. ROXget's event-handling needs work. You need to add timeout and configure request event handler. When you do e.g. a shade/unshade the rox.window doesn't get redrawn. Maybe with DSL the refresh rate is fast enough (too fast obviously). For modem users it looks like ROXget has locked up at times. |
From: Lucas H. <lu...@di...> - 2004-10-24 02:14:31
|
On Sat, 23 Oct 2004 21:27:41 +0000 Guido Schimmes <__g...@we...> wrote: > ROXget's event-handling needs work. You need to add timeout and > configure request event handler. When you do e.g. a shade/unshade the > > rox.window doesn't get redrawn. Maybe with DSL the refresh rate is > fast enough (too fast obviously). For modem users it looks like > ROXget has locked up at times. Yes, the event handling is very simple minded. I will have a crack at a better solution once i finish this assignment. -- Lucas Hazel <lu...@di...> Student, BSDfreak University of New England (http://cs.une.edu.au) Armidale, Australia [http://www.digitillogic.net] ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." (Mark Twain) ================================================= |