View Issue Details

IDProjectCategoryView StatusLast Update
0002948ScribusScripterpublic2010-05-14 22:28
ReporterTomK32 Assigned Tojghali  
PrioritylowSeveritymajorReproducibilityalways
Status closedResolutionfixed 
PlatformMacOSXOSMacOSXOS Version10.4 Tiger
Product Version1.3.2cvs 
Fixed in Version1.3.2cvs 
Summary0002948: scripter constantly grabs focus if running a long script
DescriptionScripter always forces Scribus to focus, making my desktop unusable for the time the script runs.
I didn't test it with anything else but a long script with many insertText().
TagsNo tags attached.
Patch

Relationships

child of 0003813 acknowledged Metabug: Scripter 

Activities

plinnell

2006-01-01 00:27

viewer   ~0007875

This also happens on win32

ringerc

2006-01-01 04:32

reporter   ~0007877

The scripter commands shouldn't be doing anything to explicitly grab focus, but it's entirely possible that something within the core app that the scripter uses does (perhaps a QWidget::show() call or something) .

I'll see if I can reproduce this on GNOME.

cbradney

2006-01-01 08:08

administrator   ~0007880

I bet its calling something in the view that is updating the properties palette. Selection in the scripter needs fixing.

ringerc

2006-01-01 14:10

reporter   ~0007884

I can't reproduce this on Linux/GNOME using the attached script. Either my script doesn't trigger the issue, Metacity ignores some WM hint, or there's some behaviour that Qt interprets a bit differently on Mac OS and win32 to how it does on X11.

2006-01-01 14:11

 

focusgrab_test.py (268 bytes)   
# -*- coding: utf-8 -*-

import scribus

t = "t"
scribus.createText(100,100,100,100, t)
for i in range(1,10000):
    scribus.setText("fredfredfredfred", t)
    scribus.insertText("abcd", -1, t)
    scribus.insertText("xxxx", 0, t)
    scribus.insertText("ABCD", 5, t)
focusgrab_test.py (268 bytes)   

ringerc

2006-01-01 14:13

reporter   ~0007885

As for selection in scripter, I can barely bring myself to even look at it until the view/doc is a bit less tangled.

Then, I really want to get rid of the entire concept of:
   - working in document units (the user can just write "10*mm" if they want mm)
   - The "selected object(s)" (the user can create a Selection and operate on it, or pass it as the "object" to scripter functions. Code that manipulates the contents of frames should be clearly separate to that which manipulates whole page objects.)

This would clean out quite a bit of cruft, and help move the scripter toward being a bit more maintainable.

ringerc

2006-01-02 15:06

reporter   ~0007893

As I can't reproduce this, given the time I have available I don't think I'll be able to work on this. I realise it's a pain, but I'm going to flag it low priority anyway. There are lots of other things that need doing first, and scripter isn't 0000001 priority in the 1.3.x devel series.

plinnell

2006-01-10 23:52

viewer   ~0008016

Reminder sent to: jo-hannes

subik

2006-01-11 11:43

manager   ~0008030

I cannot reproduce it (suse10, gentoo). I'll test win later.

cbradney

2006-01-14 22:50

administrator   ~0008094

Can't replicate here either

jo-hannes

2006-01-14 23:43

developer   ~0008099

you can easily reproduce on windows: start font sample script and try to switch to another window to work there. wont work as scribus grabs the focus again and again.

ringerc

2006-01-15 07:12

reporter   ~0008102

In that case, we need someone on win32 or Mac OS X to step through Scribus's execution as it runs a script, and find out at what points windows get raised. Time to get friendly with your local debugger.

cbradney

2006-01-16 10:13

administrator   ~0008124

Seems fine here on XP SP2 with the current build

plinnell

2006-01-16 10:39

viewer   ~0008126

avox reported last night via IRC his current working version was OK. I also tested the latest build with Win2k. It seems having Scribus maximized *may* affect this, but as far as I am concerned, after a fair amount of testing last night on Win2k is it OK now.

donatzsky

2010-05-14 21:33

reporter   ~0023933

Last edited: 2010-05-14 21:34

setFont() also causes this behaviour. There might be others as well, but so far I have tested:
setFontSize()
setLineSpacing()
selectText()
setTextAlignment()
and they don't cause any problems.

I'm on Windows XP, using 1.3.7svn

jghali

2010-05-14 22:28

administrator   ~0023934

Please open a new bug. That one was for 1.3.2, not 1.3.7svn.

Issue History

Date Modified Username Field Change
2005-12-31 17:28 TomK32 New Issue
2006-01-01 00:27 plinnell Note Added: 0007875
2006-01-01 00:27 plinnell Status new => confirmed
2006-01-01 04:32 ringerc Note Added: 0007877
2006-01-01 08:08 cbradney Note Added: 0007880
2006-01-01 14:10 ringerc Note Added: 0007884
2006-01-01 14:11 ringerc File Added: focusgrab_test.py
2006-01-01 14:13 ringerc Note Added: 0007885
2006-01-02 15:06 ringerc Note Added: 0007893
2006-01-02 15:07 ringerc Priority normal => low
2006-01-02 15:07 ringerc ETA none => > 1 month
2006-01-10 23:52 plinnell Note Added: 0008016
2006-01-11 11:43 subik Note Added: 0008030
2006-01-14 22:50 cbradney Note Added: 0008094
2006-01-14 23:43 jo-hannes Note Added: 0008099
2006-01-15 07:12 ringerc Note Added: 0008102
2006-01-15 12:28 plinnell Status confirmed => assigned
2006-01-15 12:28 plinnell Assigned To => jghali
2006-01-16 10:13 cbradney Note Added: 0008124
2006-01-16 10:39 plinnell Note Added: 0008126
2006-01-16 22:27 plinnell Status assigned => resolved
2006-01-16 22:27 plinnell Fixed in Version => 1.3.2cvs
2006-01-16 22:27 plinnell Resolution open => fixed
2006-01-21 00:35 cbradney Status resolved => closed
2006-05-13 21:15 christoph_s Relationship added child of 0003813
2010-05-14 21:29 christoph_s Status closed => feedback
2010-05-14 21:29 christoph_s Resolution fixed => reopened
2010-05-14 21:33 donatzsky Note Added: 0023933
2010-05-14 21:34 donatzsky Note Edited: 0023933
2010-05-14 22:28 jghali Note Added: 0023934
2010-05-14 22:28 jghali Status feedback => resolved
2010-05-14 22:28 jghali Resolution reopened => fixed
2010-05-14 22:28 jghali Status resolved => closed