Scribus > Scripts and Plugins

scribus.unGroupObject ... Look before you leap?

(1/2) > >>

Astroman Pete:
I'm profiling some code using the stable Scripter, and I'm noticing that scribus.unGroupObject takes a while, about 400 milliseconds. This adds up really fast.

I'm working with groups of objects, and if I don't ungroup objects before deleting them... bad things happen. Is there a look-before-you-leap method to tell if an object is in a group. Is there a data structure I'm missing that lists the groups and members present in the current document?

Thanks!

a.l.e:
hi pete,

there is getItemType(), but it seems to return a wrong value for groups.

all in all, please report a bug for the bad things happening (more details are needed!) on http://bugs.scribus.net!

finally, i think that you can easily browse through all the items in the document...

hth
a.l.e

Astroman Pete:
Hello Sir,

Thanks for the reply.

I'm going to optimize this time around by making the assumption that my users won't change the group structure of the objects I'm handling. That's not a great long term solution, I'd like to be able to handle whatever the pesky users throw at me, but it'll tide me over until Scripter2 stabilizes.

If I do a scribus.deleteObject on an object that belongs group, the page doesn't redraw (not even the guides); Even when the file is saved and re-opened.

I'm developing on Windows here at work. I plan on compiling a Scribus from SVN with Scripter 2 at home on my Ubuntu box to begin porting my work over to the new system. I'll check if these API calls are as expensive, and how they scale, in the new system also before filing any bugs.

a.l.e:
nice, thanks!

i really hope that a usable scribus 1.5svn + scripter 2 is only a few month away!

for now it's not meant for production, but with a bit of luck we are very close to have it usable.
cezaryace and chelen are making wonders!

ciao
a.l.e

Astroman Pete:
Just to follow-up:

This code snippet will parse the current file's XML to give you a dictionary of groups in the document. Something similar could be done to get other information difficult to find in Scripter, like the current page's Master page. This has the overhead of saving the file, of course.


--- Code: ---from xml.etree import ElementTree as ET

scribus.saveDoc()
tree = ET.parse(scribus.getDocName())
objects = tree.findall('DOCUMENT/PAGEOBJECT')
groups = {}
for obj in objects:
    if "ANNAME" in obj.attrib and "GROUPS" in obj.attrib:
        for g in obj.attrib['GROUPS'].split(' '):
            if g in groups.keys():
                groups[g].append(obj.attrib['ANNAME'])
            elif g != '':
                groups.update({g:[obj.attrib['ANNAME']]})

--- End code ---

This is off topic, let me know if I should start a new thread, but it appears that my application may be much faster if I closed the file in Scribus, manipulate the SLA file, then reopen it. This approach seems to work okay in Inkscape. I know the file format is in flux, as well.

It may have big performance benefits. I'm wrangling hundreds of objects. It would also have the benefit of being able to do updates/queries "gui-less", in cronjobs and what not.

The DTD in the 1.4 branch of the Subversion tree doesn't look like the files 1.4.2svn creates. Is this going to change before 1.4.2 is released?
http://scribus.net/websvn/filedetails.php?repname=Scribus&path=%2Fbranches%2FVersion14x%2FScribus%2Fdtd%2Fscribus.dtd


I found this page on the current format.  http://wiki.scribus.net/canvas/File_Format_Specification_for_Scribus_1.4#Scribus_Objects_.28SCE.29

I guess my question is, "Is it advisable to interface with the SLA file format, or is it too unstable?"

Navigation

[0] Message Index

[#] Next page

Go to full version