Hi Ronan,
My answers are below.
El 03/09/13 17:48, Ronan Paixão escribió:
Hi. Since the topic is plugin development, and I'm also starting, I'd
like to ask some questions too :-)
I just started what I believe will be a very large plugin. To be more
exact, I intend to have plugins that will complement this plugin.
Since this can become rather messy, I'd like a few directions on how
to organize it be better fit with Spyder's development.
I've noticed that non-core plugins are all mixed in a single folder.
So far, I've created a subfolder in the spyderplugins dir, and intend
to put it all there, with just a file in the root to load the other
components. Does that sound right?
Yes, that sounds pretty well.
I've also noticed that some resource are rather scattered
(Linux-style). For example, the breakpoints plugin is in the
spyderplugins dir, loading its GUI from the widgets subdir (which also
contains GUIs for the profiler and pylint plugins), and loads some
images from the /spyderlib/images dir. I understand those plugins are
rather simple and can benefit from such an arrangement, but I'm unsure
if that will fit my (probably more complex) plugin.
This is how things work: All thrid-party plugins have to go in
spyderplugins. Each plugin is represented by a p_foo.py file inside this
dir, and the widgets they embed have to go in its widgets subdir. This
is pretty much how the architecture for our core plugins work (please
read my previous answer to Lucian for a detailed explanation of the
differences between plugins and widgets).
Besides, if your plugin needs to use some images then you have to put
them in spyderplugins/images. The breakpoints plugin doesn't use any
image, because it just lists the current plugins in all files (opened or
closed). Perhaps you are referring to the breakpoint images (which are
those little red circles we use to indicate the presence of a one of
them) but those belong to Editor plugin.
I also designed my GUI with Qt Designer, which generates a .ui file. I
noticed that Spyder itself doesn't use this approach. Is there an
specific reason why that's so? From what I can tell, it's probably
because of the plugin structure, and maybe because of the different
PyQt/PySide UI code generators. Since I intend to have plugins that
will complement my "core" plugin, are there any tips in this
direction? Since I have to use another QMainWindow, is it possible
that Spyder's pluggable approach is better in the long run?
I'm not the best one to answer these questions (because I didn't start
the project) but here it's what I can tell you: besides developing our
gui, we need to do a lot of low level operations and interface with
several python libraries (e.g. to provide code completion on the
Editor), and so developing all these things in pure Python seems more
comfortable than doing some of them with Qt Designer and some with Python.
This SO question could help you to move your current ui design to a
Python file:
http://stackoverflow.com/questions/15362624/how-do-you-execute-pyqt-ui-code-in-python
As for having two QMainWindow's, according to this other post, it seems
perfectly possible:
http://stackoverflow.com/questions/318641/multiple-qmainwindow-instances
I hope to see your work in the future, it sounds very ambitious and
could show the potential Spyder has to be extended in interesting ways.
Cheers,
Carlos
Cheers,
Ronan
--
You received this message because you are subscribed to the Google
Groups "spyder" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups
"spyder" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/groups/opt_out.
