pallavi-users — Mailing list for Pallavi users, developers, and plugin maintainers

[Pallavi-users] Pallavi 0.6 beta 2 released

[Dusty P. <bu...@gm...>]

Hey all,

I've released the beta 2 of Pallavi if anyone's interested in
upgrading or testing. It fixes some issues with incremental find,
closing the view, recent documents focusing, and something else that I
forget.

Dusty

[Pallavi-users] Previous e-mail?

[Dusty P. <bu...@gm...>]

Hi Avner,

Can you confirm that you received my previous e-mail regarding the
Pallavi Windows installer -- I did reply to the original and to the
second one you sent but I'm concerned it didn't get through again.

Thanks,
Dusty

Re: [Pallavi-users] A small bug fix

[Dusty P. <bu...@gm...>]

Hi Peter,

Thanks a bunch, that almost certainly fixes another bug I've noticed
under Windows that I absolutely could not explain, namely that it
couldn't find the config skeleton when copying "pallavi_config". I've
committed the fix to svn and it will show up in 0.6 beta 2.

Dusty

On 20/10/2007, Peter Garceau <pga...@gm...> wrote:
> Hey everyone,
> On windows I've been having a problem with pallavi not being able to find
> the pallavi128.xmp for a while and I decided to take a look at it today. It
> turns out that on windows, the os.path.join() function will ignore all of
> the path information in it's first argument if it's given an absolute path
> for it's second argument. The long and short of it is that on line 75 of
> pallavi.py, the line:
>
> config_skeleton = os.path.join(sys.prefix,
> "/share/pallavi/pallavi_config.py")
>
> ends up setting config_skeleton equal to
> /share/pallavi/pallavi_config.py, dropping the while
> sys.prefix part eliminating the leading / in the second argument so that it
> looks like this:
>
> config_skeleton = os.path.join(sys.prefix,
> "share/pallavi/pallavi_config.py")
>
> fixes the problem and allows pallavi to look in the correct folder for the
> xpm (C:\Python25\share\pallavi).
>
> Peter
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Pallavi-users mailing list
> Pal...@li...
> https://lists.sourceforge.net/lists/listinfo/pallavi-users
>
>

[Pallavi-users] A small bug fix

[Peter G. <pga...@gm...>]

Hey everyone,
On windows I've been having a problem with pallavi not being able to find
the pallavi128.xmp for a while and I decided to take a look at it today. It
turns out that on windows, the os.path.join() function will ignore all of
the path information in it's first argument if it's given an absolute path
for it's second argument. The long and short of it is that on line 75 of
pallavi.py, the line:

config_skeleton = os.path.join(sys.prefix,
"/share/pallavi/pallavi_config.py")

ends up setting config_skeleton equal to /share/pallavi/pallavi_config.py,
dropping the while sys.prefix part eliminating the leading / in the second
argument so that it looks like this:

config_skeleton = os.path.join(sys.prefix,
"share/pallavi/pallavi_config.py")

fixes the problem and allows pallavi to look in the correct folder for the
xpm (C:\Python25\share\pallavi).

Peter

[Pallavi-users] Pallavi 0.6 Beta 1 released

[Dusty P. <bu...@gm...>]

Hey all,

I just pushed out the Pallavi 0.6 beta 1 release; you're probably
aware of the changes from previous e-mails, but here's a summary:

- Multiple top-level windows with some support for moving docking
windows between them
- Ability to associate arbitrary mode-dependent values with lexer modes
- Several new actions useful to programmers (indenting and dedenting,
line comment, etc)
- Abbreviations Plugin
- Several possible configuration files

Noteably: there are very few bugfixes! Apparently I did a good job of
testing before making the 0.5 release. I hope to do that again with
the 0.6 release; I expect there are quite a few bugs waiting to be
tracked down in this beta release, as there was a fair bit of
structural change to support the multiple views. Any testing,
comments, criticisms, patches, money, or other feedback are, as
always, much appreciated. (especially patches. :-)

Dusty

Re: [Pallavi-users] Windows installer

[Dusty P. <bu...@gm...>]

On 12/10/2007, Avner Ben <av...@sk...> wrote:
> "Dusty Phillips" <bu...@gm...> wrote...
>
> > While investigating this issue, I was told that the usual way to
> > distribute wxPython apps on Windows is to use py2exe. I played with
> > this a bit, but I was unable to get a working py2exe version of
> > Pallavi.
>
> Dusty,
>
> Py2exe seems abandoned. The last version is of late 2006 and is not - repeat not - compatible with Python 2.5.

Thanks for the info, I didn't know that.... the people on
wxPython-users seem to be quite in favour of its use.


> I used to package Skilltree with Py2exe but since Python 2.5, have switched to PyInstaller 1.3. However, this only takes care of the executable. You still need a windows-style installer. For this, I am using Inno setup. I did have to write a python script to bundle it all together. I don't remember what who the complications because it was along time ago, but it obviously was not straightforward.
>
> I could attempt to adapt the script for Palavy, but not in the next couple of days.

It would be great if you could give it a go sometime, but no rush --
in the meantime I think I'll release a beta using the setup.py
bdist_wininst installer.

I suspect this would be a fairly complicated installer because Pallavi
is not self-contained. Python modules need to be loaded from an
external path (pallavi_config.py, for one, along with any external
plugins and the lexer plugins), and the program needs to access the
external user configuration directory.

Thanks,
Dusty

[Pallavi-users] Windows installer

[Avner B. <av...@sk...>]

"Dusty Phillips" <bu...@gm...> wrote...

> While investigating this issue, I was told that the usual way to
> distribute wxPython apps on Windows is to use py2exe. I played with
> this a bit, but I was unable to get a working py2exe version of
> Pallavi.

Dusty,

Py2exe seems abandoned. The last version is of late 2006 and is not - repeat not - compatible with Python 2.5. I used to package Skilltree with Py2exe but since Python 2.5, have switched to PyInstaller 1.3. However, this only takes care of the executable. You still need a windows-style installer. For this, I am using Inno setup. I did have to write a python script to bundle it all together. I don't remember what who the complications because it was along time ago, but it obviously was not straightforward.

I could attempt to adapt the script for Palavy, but not in the next couple of days.


	Avner.

Re: [Pallavi-users] New and Improved Pallavi Crypto, plus submenus!

[Dusty P. <bu...@gm...>]

On 11/10/2007, Peter Garceau <pga...@gm...> wrote:
>  Why have an editor that
> is completely modular, and then have one monolithic configuration file for
> everything? I agree that some plugins don't require a whole file for only 2
> or 3 config options, but I can think of at least 6 or 7 things that would be
> nice to have configurable in the PyCryptopallavi module, along with some
> good comments explaining what they each do and what their options are that
> would fit nicely in a separate config.
>
> Thoughts, comments?

I agree. Now, I haven't tested this, but I *think* this is already
supported (thank you Guido, for the use of your time machine :-D); if
not it should just require adjusting sys.path a bit.

Basically, create your external configuration file and save it in the
config directory (for example, save it as mypluginconfig.py). Then
inside the "main" pallavi_config, use this syntax:

from mypluginconfig import *

Yes, this syntax is generally frowned upon in Python, but for this
specific usage, it is ideal. I'm not 100% certain it will work, but
feel free to test it and see. :-)

On a related note, in the latest subversion, I added several different
configuration files that can be used as examples or bases:
minimal_config.py, default_config.py, and python_ide_config.py. To
use, simply save one of these files as your
~/.pallavi/pallavi_config.py and edit.

Dusty

Re: [Pallavi-users] New and Improved Pallavi Crypto, plus submenus!

[Peter G. <pga...@gm...>]

I experienced the behavior you mentioned while I was writing the plugin, but
it had appeared to be fixed on my end. I'm indeed using windows though, so
that's probably why I missed it the second time, thanks for taking care of
it.

Now that pallavi has pretty much all of the menu functions that it'll
realistically need (which is the kind of stuff that always ends up being a
pain in the ass, if you ask me) I'll be able to focus on having
PyCryptoPallavi do neat stuff. One thing that I've been meaning to ask is
what people's thoughts were about plugin specific configuration files in the
pallavi configuration folder. I think it would be a little cleaner and
easier to work with if PyCryptoPallavi had a seperate configuration file,
instead of adding all of the options to pallavi_config.py, and I think it
makes sense with the way that pallavi is designed.  Why have an editor that
is completely modular, and then have one monolithic configuration file for
everything? I agree that some plugins don't require a whole file for only 2
or 3 config options, but I can think of at least 6 or 7 things that would be
nice to have configurable in the PyCryptopallavi module, along with some
good comments explaining what they each do and what their options are that
would fit nicely in a separate config.

Thoughts, comments?

Peter Garceau

Re: [Pallavi-users] New and Improved Pallavi Crypto, plus submenus!

[Dusty P. <bu...@gm...>]

> Hmm... I applied the patch and immediately got some bugs from trying
> to append a menuitem to "None" I tracked those down and fixed them,
> then I decided to refactor the code a bit and moved the duplicate code
> out of BindMenuAction and BindMenuFunction into a separate
> GetMenuOrSubmenu function. Then everything ran ok and I was able to
> add the menubar.... But when I installed PyCryptoPallavi, I found that
> it added the submenu properly to the plugins menu, but then instead of
>  adding the new menu items to that plugin, it added two new Plugins
> menus! This may be due to the way the if tuple in... code is set up,
> or it could be due to this bug:
> http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?11:mss:69062:200710:jfemmgdhhkfhpjkhcbeg
>
> I've committed the current version to svn if you want to check it out
> and play with it; I don't have time to look into the bug for a while.

I lied, I did have time, and the bug was related to the link I gave...
I committed a workaround, but the problem should disappear in newer
versions of wxPython. I'm guessing it didn't show up at all on windows
installs, only the gtk version.

Tried out the Encryption plugin too... it works great! :-) Thanks a
lot for the contribution. I'm going to add an entry for this plugin in
the default Pallavi config so other users are aware of it.

Dusty

[Pallavi-users] Anyone want to create a Windows Installer?

[Dusty P. <bu...@gm...>]

Hey all,

I'm planning on making a Pallavi 0.6 beta 1 release in the next couple
of days. With the public release of 0.5, I was surprised by the number
of Windows users interested in Pallavi... the support for Windows
isn't terribly good in that version, and the windows installers make
the assumption that Python is installed to C:\Python25. I think I've
fixed this specific issue, but windows installations are still a bit
shaky. I think Pallavi runs fine on Windows, but getting it to install
and set up can be tricky.

While investigating this issue, I was told that the usual way to
distribute wxPython apps on Windows is to use py2exe. I played with
this a bit, but I was unable to get a working py2exe version of
Pallavi.

I was wondering if any windows users out there would have the time and
patience to adjust my setup.py to work with py2exe and create a more
generic installer?

If not, I'll likely look into it later, but will probably release the
beta 1 with the same type of installer as previously.

Dusty

Re: [Pallavi-users] New and Improved Pallavi Crypto, plus submenus!

[Dusty P. <bu...@gm...>]

> Hey All,
> I'm not sure if anyone really used the GPGPallavi plugin for anything except
> amusement, but for anyone who's interested anyway I've finished up it's
> successor, PyCryptoPallavi to the
> point where I'm willing to release it.
<snip>

Nice plugin. I didn't actually try it out yet, but thanks for
documenting it. :-) The code looks clean.

> On top of all that, while I was writing this module, I decided that it might
> be nice to be able to have some action that creates submenus, so I've
> created yet another patch for
> SimpleMenubar.py that adds this action. I've attached that to the end of
> this mail if anyone is interested.

Hmm... I applied the patch and immediately got some bugs from trying
to append a menuitem to "None" I tracked those down and fixed them,
then I decided to refactor the code a bit and moved the duplicate code
out of BindMenuAction and BindMenuFunction into a separate
GetMenuOrSubmenu function. Then everything ran ok and I was able to
add the menubar.... But when I installed PyCryptoPallavi, I found that
it added the submenu properly to the plugins menu, but then instead of
 adding the new menu items to that plugin, it added two new Plugins
menus! This may be due to the way the if tuple in... code is set up,
or it could be due to this bug:
http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?11:mss:69062:200710:jfemmgdhhkfhpjkhcbeg

I've committed the current version to svn if you want to check it out
and play with it; I don't have time to look into the bug for a while.

Dusty

[Pallavi-users] Multiple top-level views

[Dusty P. <bu...@gm...>]

Hey all,

I've just completed a massive but fairly simple restructuring of
Pallavi to allow multiple top-level windows to be open at one time
(ie: for multi-monitor displays and such). The cool thing is that it
doesn't have much effect on plugin developers, although your plugin
does have to be aware of this fact now. Plugins no longer receive a
"view" variable to work with, but instead get a "pallavi" variable,
which contains a "focusedView" variable and a "views" variable. It
also issues "ViewCreated" events when a new view is created. Different
plugin styles will have to interact with one or more of these.

This is the major feature I wanted to implement for 0.6. I've also
coded up a few plugins and will be doing a few more simple ones before
I release the beta, but that should be coming out "soon". I think I'm
going to have to do a little "make windows users happy" work as well,
as there's more interest from users of that OS than I ever expected.

It could be a while before the beta release comes out, since I'm
moving across the country on Tuesday (back to Toronto if anyone's
interested in my personal life or lives in the area and wants to meet
at the Linux Cafe ;-).

Dusty

Re: [Pallavi-users] A little bit of feedback, and a new plugin

[Dusty P. <bu...@gm...>]

On 23/09/2007, Peter Garceau <pga...@gm...> wrote:
> I haven't had much time to play around with pallavi this last week, so this
> took a while for me to mention but your last update to SimpleMenubar is
> broken if a menu isn't actually present. wx throws a fatal error when
> GetMenu is called if the menu doesn't exist, which crashes pallavi (at least
> on windows it does). I fixed it by catching the exception like this:
>
> In BindMenuAction
> Before
>
> menu = menubar.GetMenu(menubar.FindMenu(menuname))
>
> After
>
> try:
>     menu = menubar.GetMenu(menubar.FindMenu(menuname))
> except wx._core.PyAssertionError:
>     menu = None

Oops, that was a nasty little oversight. Thanks for that; I've added
the fix to svn.

Dusty

Re: [Pallavi-users] A little bit of feedback, and a new plugin

[Peter G. <pga...@gm...>]

I haven't had much time to play around with pallavi this last week, so this
took a while for me to mention but your last update to SimpleMenubar is
broken if a menu isn't actually present. wx throws a fatal error when
GetMenu is called if the menu doesn't exist, which crashes pallavi (at least
on windows it does). I fixed it by catching the exception like this:

In BindMenuAction
Before

menu = menubar.GetMenu(menubar.FindMenu(menuname))

After

try:
    menu = menubar.GetMenu(menubar.FindMenu(menuname))
except wx._core.PyAssertionError:
    menu = None


Peter

[Pallavi-users] Preparation for Multiple Views

[Dusty P. <bu...@gm...>]

Hey all,

I just committed a bunch of changes to svn to pave the way for
allowing multiple views (edit windows) to be opened at one time. The
primary change of interest to plugin developers is that plugins no
longer have a "view" variable preset when they are created. Instead,
there is a new "pallavi" variable, and to get the currently focused
view, you can use:

pallavi.focusedView

To access all the views, you can iterate through:

pallavi.views

This is, unfortunately, going to make plugins a little harder to
develop and a little uglier code, but the payoff is the ability to
have multiple windows open at one time, all communicating with the
same set of plugins. This has been a frequently requested feature
(where frequent = 3 times)

Multiple views are not actually available yet (pallavi.focusedView
always refers to the same view and pallavi.views contains only that
one item). I will be working on this later. The primary issue at this
time is how to make multiple views work with the docking manager; each
plugin may have to provide a panel for more than one view and manage
these views separately. I think I should have a nice long sleep and
wake up with a good idea before I start on that. ;-)


Dusty

[Pallavi-users] Some neat stuff

[Dusty P. <bu...@gm...>]

Hey all,

Got a couple of neat announcements to make. First, I just committed
some changes to the ActionManager that allows you to send an arbitrary
number of arguments. So you don't have to send data as a tuple before.

Before:
actions.Invoke('BindMenuAction', ("&Plugins", "RetrievePlugin"))
After
actions.Invoke('BindMenuAction', "&Plugins", "RetrievePlugin")

I've reworked the BindMenuAction to use it as above, and also the
RequestUserInput action, Any plugins that use these actions will need
updating. All other existing actions remain unaffected. If you use
actions with multiple arguments in a single tuple as data, you can
change them now, but its not required.

Second, I've been talking to a guy named Claudio Grondi who has worked
with Ulipad a bit. He suggested in a roundabout way that it could be
useful to utilize the interactive interpreter for macros -- ie:
control Pallavi from the Python Interpreter provided by the
PythonShell plugin. I fiddled with it a bit and found out its possible
without changing a line of code. Wow! (My first ever Guido's Time
Machine moment!) Once you have access to the view, you can access any
other stuff like the config, focusedTextView, pluginManager etc. Check
this out, for example:

>>> import wx
>>> app = wx.GetApp()
>>> view = app.GetTopWindow()
>>> tv = view.focusedTextView
>>> for j in range(6):
...     tv.AddText("7%i\n"%j)

Finally, I'm currently working on making the Lexer plugin allow
arbitrary values to be saved on a per-language basis. This will be
utilized first for specifying a "comment-character" to allow lines of
code to be automatically commented out.

Avner: This work may come in handy for your mode-specific quest.

BTW, I'm considering renaming the Lexing plugin to EditModes or
something. This will help reduce confusion with the wx.stc lexer stuff
(a lower level than the plugin), and will also be more aligned with
the terminology utilized by other text editors. Any comments?

Dusty

Re: [Pallavi-users] A little bit of feedback, and a new plugin

[Dusty P. <bu...@gm...>]

> I agree with you all the way that the changes I've suggested don't really
> deserve their own plugin. I went back and I made some changes to
> SimpleMenubar.py and PluginRetriever.py that I think will add everything I
> was thinking about adding. SimpleMenubar now creates two actions for
> BindAction and BindFunction that can be invoked by any plugin.
> PluginRetriever has been updated to take advantage of these new actions.
> I've attached patches for both of these files, let me know what you think.

Hi Peter,

I've incorporated your changes into the two plugins. I modified it a
bit to make the SimpleMenubar do the GetPlugin and FindPlugin instead
of forcing each outside plugin to perform this task. Also, if you ask
it to find a menu that doesn't exist it will automatically add them.
These changes are incorporated into subversion.

I haven't thoroughly tested it.

> I've been using the API pretty extensively since you created. It's pretty
> nice to use, especially since you comment your code so well. It's nice to
> have some actually explanations for functions, unlike many pydocs out there
> that give you names and just about nothing else.

I'm glad they're useful. :-) I find that commenting a lot is a key to
organized code.

That reminds me, I also added comments to the two plugins saying that
the one provides two new actions and that the other utilizes one.

Thanks for doing and suggesting this, its a great way to deal with
menu management.

Dusty

Re: [Pallavi-users] My own lexer and in Python (not C)

[Avner B. <av...@sk...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Dusty Phillips wrote:
<blockquote
 cite="mid:7ec...@ma..."
 type="cite"><br>
  <pre wrap="">wxSTC doesn't associate a lexer with an extension. Currently there is
a plugin in Pallavi that scans filesystems and sets the lexer based on
the file extension. It should be possible to either adapt this plugin
or create a similar one that calls another plugin instead.
  </pre>
</blockquote>
OK with me.<br>
<blockquote
 cite="mid:7ec...@ma..."
 type="cite"><br>
  <pre wrap="">With Pallavi's design, I don't think you'd want to create a single
monolithic plugin that retains control like this. Pallavi is very
modular; I think you would probably rather have a plugin that sets up
a few listeners (for keystrokes, focus events, etc). When an event
comes in on these listeners, I would suggest checking to see if the
currently focused buffer is "managed" by your plugin (ie: has a
.design extension), and then do the lexing on it.
  </pre>
</blockquote>
I have to think about that. Since listeners seem to register globally
(rather than for the active window), then the possibility for a number
of listeners to the same event can mean conflict.<br>
<blockquote
 cite="mid:7ec...@ma..."
 type="cite"><br>
  <pre wrap="">I would suggest having separate plugins for each of these activities
as well. Pallavi has no support for the latter two features yet, but
it would be neat if a language-agnostic plugin could be designed to do
this. In my mind such a plugin would NOT have structural information,
but would rely on a separate plugin to provide this kind of
information based on the language.
  </pre>
</blockquote>
In the "trusty's own lexer"code, the OnStyleNeeded handler does all
three tasks in the same breath!<br>
I am not sure what you mean by structural information. To do syntax
highlighting one needs some kind of tokenization. To do meaningful
auto-completion, one needs to know the context (module, class, method,
etc.) and that does mean structural information.<br>
<br>
<blockquote
 cite="mid:7ec...@ma..."
 type="cite"><!----><br>
  <pre wrap="">I think it is feasible, though all the core support may not be
available yet. Again, it comes down to listeners -- You could have a
plugin that checks each time a textview is focused to see if it is one
that is managed. If it is, it could then add the menu entries and
ensure the tree-control is visible, if not, it can do the reverse.
  </pre>
</blockquote>
Yes, "managed" is the keyword. Although it is possible to do it this
way, I would rather see a clean methodical solution, involving, in
addition to "plugin' also "managers", which are plugin containers,
associated by the system with file extension, overriding lexers. <br>
<blockquote
 cite="mid:7ec...@ma..."
 type="cite">
  <pre wrap="">
As for within my plans, I do have it in mind to provide lexing support
for more languages than scintilla provides. </pre>
</blockquote>
I believe the problem with that is that - if I got it right - to add a
lexer (an enumeration, really), you must touch a C h file and recompile
the system, which seems to be beyond the power of python.<br>
<br>
&nbsp;&nbsp;&nbsp; Avner.<br>
</body>
</html>

Re: [Pallavi-users] My own lexer and in Python (not C)

[Dusty P. <bu...@gm...>]

> the problem is that wxSTC associates a _lexer_ with file extension. What
> I need from Pallavi is the ability to associate a plugin with file
> extension.

wxSTC doesn't associate a lexer with an extension. Currently there is
a plugin in Pallavi that scans filesystems and sets the lexer based on
the file extension. It should be possible to either adapt this plugin
or create a similar one that calls another plugin instead.

> Whenever the user opens a file with '.design' extension,
> control goes to my plugin and remains there for as long as the edit
> window is active.

With Pallavi's design, I don't think you'd want to create a single
monolithic plugin that retains control like this. Pallavi is very
modular; I think you would probably rather have a plugin that sets up
a few listeners (for keystrokes, focus events, etc). When an event
comes in on these listeners, I would suggest checking to see if the
currently focused buffer is "managed" by your plugin (ie: has a
.design extension), and then do the lexing on it.

> My plugin surrenders control when another edit window
> becomes active. Actually, this goes beyond just syntax highlighting,
> autocompletion and call-tips.

I would suggest having separate plugins for each of these activities
as well. Pallavi has no support for the latter two features yet, but
it would be neat if a language-agnostic plugin could be designed to do
this. In my mind such a plugin would NOT have structural information,
but would rely on a separate plugin to provide this kind of
information based on the language.

> For example, my plugin would benefit from
> additional menu entries, specific to the language, such as "compile",
> "revert", "open graphic inspector", "find declaration" etc. I would like
> these menu entries to be disabled in other edit windows, of course (or
> disappear altogether, as in the MDI model). I would like to show a tree
> control (side by side with the text) and have it disappear, too, and
> much more.
> I wonder it this is feasible (or within your plans)...

I think it is feasible, though all the core support may not be
available yet. Again, it comes down to listeners -- You could have a
plugin that checks each time a textview is focused to see if it is one
that is managed. If it is, it could then add the menu entries and
ensure the tree-control is visible, if not, it can do the reverse.

As for within my plans, I do have it in mind to provide lexing support
for more languages than scintilla provides. The other features are
things that I can see the utility of, but don't personally have much
interest in developing at this time (just more urgent other features
at this time). However, the beauty of Pallavi, if I've designed it
right, is that you should be able to create all this support as a
collection of plugins that can be shipped independently from Pallavi.

Dusty

[Pallavi-users] My own lexer and in Python (not C)

[Avner B. <av...@sk...>]

OK, so I have looked at a couple of examples and understood that, to do 
my own syntax highlighting etc, I need to start with...

            self.SetLexer(stc.STC_LEX_CONTAINER)
            self.Bind(stc.EVT_STC_STYLENEEDED, self.OnStyleNeeded)

...and proceed as in the examples. (A thorough example is in "PyCrust'S 
own lexer" - http://del.icio.us/harryf/scintilla).
However, all these examples are standalone windows that know in advance 
what they are going to edit.
the problem is that wxSTC associates a _lexer_ with file extension. What 
I need from Pallavi is the ability to associate a plugin with file 
extension. Whenever the user opens a file with '.design' extension, 
control goes to my plugin and remains there for as long as the edit 
window is active. My plugin surrenders control when another edit window 
becomes active. Actually, this goes beyond just syntax highlighting, 
autocompletion and call-tips. For example, my plugin would benefit from 
additional menu entries, specific to the language, such as "compile", 
"revert", "open graphic inspector", "find declaration" etc. I would like 
these menu entries to be disabled in other edit windows, of course (or 
disappear altogether, as in the MDI model). I would like to show a tree 
control (side by side with the text) and have it disappear, too, and 
much more.
I wonder it this is feasible (or within your plans)...

    Avner.

Re: [Pallavi-users] A little bit of feedback, and a new plugin

[Dusty P. <bu...@gm...>]

Hi Peter,

I applied your patch to the PluginRetriever and committed the changes.

For the pluginsmenu plugin, I have a few questions/suggestions. First,
I think the code that adds the PluginRetriever to the menu should be
placed in the PluginRetriever plugin itself -- I have no problem with
that.

Second, how do plugins that want to utilize this plugin access the
BindAction and BindFunction functions? Do they have to import the
plugin directly?

I'd like for Pallavi plugins to not have to depend on each other this
way. I think a better way would be to provide two new actions that
plugins can call if they want to add items to the menu; the required
information could be provided in a tuple as the data to the actions.
The only catch would be that the pluginsmenu plugin would have to be
loaded before any other plugins in the pallavi_config.

I think the StatusBar plugin uses a similar structure to what I'm
suggesting if you want to look at it; other plugins can set the
message by issuing a SetStatus action or some such. The UserRequest
plugin may also give you something to base your code on. If I can free
up some time I'll look into it myself too; I think this is a great
idea. I had originally had this vague idea that a special plugin could
scan all the available actions and add them to the menu somehow, but
this way is much better; let the plugins take care of it.

By the way, have you found the developers API at all useful in your work?
http://pallavi.sourceforge.net/pydoc/

Dusty

Re: [Pallavi-users] SameIndent plugin bug report

[Dusty P. <bu...@gm...>]

On 14/09/2007, Avner Ben <av...@sk...> wrote:
> Hello,
>
> The "same indent" plugin does not work properly, due to missing function
> call brackets:

Thanks a lot for tracking that down... what a goofy mistake! I've
committed the fix to subversion.

Dusty

>
> Compare: (<)C:\Python25\Lib\site-packages\pallavi\plugins\SameIndent.bak
> (2372 bytes)
>    with: (>)C:\Python25\Lib\site-packages\pallavi\plugins\SameIndent.py
> (2343 bytes)
>
> 45c45
> <     if not ((event.AltDown or event.ControlDown() or event.ShiftDown())):
> ---
>  >     if not ((event.AltDown() or event.ControlDown() or
> event.ShiftDown())):
>
>     Avner.

[Pallavi-users] SameIndent plugin bug report

[Avner B. <av...@sk...>]

Hello,

The "same indent" plugin does not work properly, due to missing function 
call brackets:

Compare: (<)C:\Python25\Lib\site-packages\pallavi\plugins\SameIndent.bak 
(2372 bytes)
   with: (>)C:\Python25\Lib\site-packages\pallavi\plugins\SameIndent.py 
(2343 bytes)

45c45
<     if not ((event.AltDown or event.ControlDown() or event.ShiftDown())):
---
 >     if not ((event.AltDown() or event.ControlDown() or 
event.ShiftDown())):

    Avner.

Re: [Pallavi-users] A little bit of feedback, and a new plugin

[Dusty P. <bu...@gm...>]

Perhaps that particular feature should be put in the RetrievePlugin
itself? Its not up to the menubar to know what plugins are loaded.

Dusty

On 11/09/2007, Peter Garceau <pga...@gm...> wrote:
> As a quick update, I took a look at adding the pluginsmenu to simplemenubar
> and It doesn't really look like a good option. The problem is the order in
> which plugins are loaded. Since simplemenubar is one of the core plugins and
> RetrievePlugin is one of the "optional" ones, simple menubar can't add the
> RetrievePlugin action as a menu option.
>
> Peter
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Pallavi-users mailing list
> Pal...@li...
> https://lists.sourceforge.net/lists/listinfo/pallavi-users
>
>