Skip to content

IssuesUnderLinux

Jump to bottom Edit New page
Christian Ziemski edited this page Mar 7, 2016 · 6 revisions

Issues Under Linux

Issues with Images ?

  • Using with Debian, it doesn't seem to display images as promised in the help pages. Instead it displays a token image (image with an X in it). It does this even with the example image in the help files.

    • Images don't seem to work under Ubuntu Gutsy either.

  • Under Ubuntu Hardy (at least), this issue can be solved modifying the file $WIKIDPAD_DIR/lib/pwiki/Exporters.py, line 1731, by changing:

 link = wx.FileSystem.FileNameToURL(p)

to:

 link = wx.FileSystem.FileNameToURL(p[5:])

this is only a dirty hack that eliminates the file: prefix that causes the unexpected issue with images, when passed as parameter to FileNameToURL in Ubuntu (this function generates "file:" + the current working dir + content of p, when p is not an usual filesystem path. If p starts with file:, it's not recognized as an usual path)

Issues with space for tree view

There are some issues with the tree view under Debian.

  • The default view is too small horizontally. My workaround, and I'm not sure it wasn't voodoo, was to change the line

      ("main", "splitter_pos"): '170',

  in lib/pwiki/Configuration.py, to

  ("main", "splitter_pos"): '300',

  • The the tree can only be expanded horizontally with great difficulty. You have to hover over the vertical split line and try to grab it. Only about once every 4 times do you actually manage to get the separator line. Interestingly, if you put the tree on the right hand side the separator line is easy to manipulate.

  • If you put the tree on the bottom, the separator line is easy to move, but the actual space used by the tree doesn't change, leaving a large blank area.

Issues with workarounds

  • Help - the WikidPad help system uses a Windows-only function to launch, and does not work under Linux. As a workaround, you can use the File/Open menu to navigate to the WikidPadHelp.wiki file, or, edit PersonalWikiFrame.py and replace the openHelp function with the following, substituting the command you use to start WikidPad for "wikidpad" in the sample below :

      def openHelp(evt):
      os.popen2("wikidpad %s" %self.wikiPadHelp)

    A script to launch wikidpad could look like this:

#!/bin/sh cd /usr/share/wikidpad export PYTHONPATH=lib python WikidPad.py $1


An alternative might look like this:

```default
#!/bin/sh
WIKIDPATH="/usr/share/wikidpad" # where you installed the wikidpad sources
export PYTHONPATH=$WIKIDPATH/lib
python $WIKIDPATH/WikidPad.py $*

save this as wikidpad (and make executable: "chmod ug+x wikidpad"). If this script is in your $PATH (e.g. in /usr/local/bin), then you don't need to alter anything for help to work.

  • Better to use export PYTHONPATH=$PYTHONPATH:$WIKIDPATH/lib so you don't overwrite you existing PYTHONPATH

  • Linux comment. - The above script fails. Move pwiki and gadfly out of "WikidPad/lib" to run program. Python import statements otherwise break with or without PYTHONPATH. (Python 2.4.4, Debian Etch) To run from your home folder, which seems only rational since wp isn't Python-packaged at all, but EXE'd, do these steps in Linux.

    Use Linux package manager to install Python, wxWidgets (but not gadfly or pwiki).

    Download source zip archive to your user home folder and re-configure. Example,

cd ~/ wget --output-document=source.zip http://www.jhorman.org/wikidPad/WikidPad-1.8rc2-src.zip mkdir WikidPad unzip source.zip -d WikidPad mv WikidPad/lib/gadfly WikidPad mv WikidPad/lib/pwiki WikidPad rm -r WikidPad/lib


  Then create a simple launch script wikid.sh like
  ```default
#!/bin/sh
cd ~/WikidPad ; env PYTHONPATH='pwiki:gadfly' python WikidPad.py $1

Not forgetting

chmod ug+x ~/wikid.sh

Invocation as ./wikid.sh or use your favorite desktop icon association.

We should not have to do this. Python has a packaging system for site-packages and all that.

  • Opening http:// links in browser window add

    import webbrowser

    to the import list of PersonalWikiFrame.py, and change all instances of

    os.startfile

    to

    webbrowser.open

    [http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/347810]

    All file links in the wiki must then also be in url format, ie file:///home/me/file.pdf and will be opened in your web browser

  • Opening browser window for urls - additional note

Note: for Ubuntu 7.04, Python 2.5.1, Firefox 2.0.0.4 I found it was necessary to change line 3049 in PersonalWikiFrame.py from

wx.LaunchDefaultBrowser(link2) # TODO

to

webbrowser.open_new(link2)

(this is probably why the author put a "todo" there!).

  • Opening browser window for urls - additional note (2)

    With some versions of python the webbrowser.open_new() function runs in the foreground. This means the url will be opened up and WikidPad will stall until you close the web browser. To overcome this the following "dirty fix" can be used:

instead of webbrowser.open_new(link2)

use

os.system('/usr/bin/konqueror %s &' % link2)

or replace "konqueror" with the preferred web browser. This ensures the browser runs in the background and you still have full control of WikidPad

  • Opening browser window for urls - additional note (3) My wikidpad now opens links in firefox without changing the code. I added

    firefox

to the 'File Launcher' section on the Options page

Operation of Cut, Paste and Copy

These do not seem to work on the Linux version of WikidPad. The base Cut(), Paste() and Copy() methods seem to have been replaced in the derived class WikiTxtCtrl. This could possibly be due to problems associated with wxWidgets under windows. However, simply using the base class methods in linux removes the problem. This can be done by commenting out or removing the Cut(), Paste() and Copy() methods in the file pwiki/WikiTxtCtrl.py (can be found around line 356, between the close() and onCmdCopy() methods).

  • Selection not copied to linux clipboard for middle-mouse-button paste

Note on the above: it seems that the copying to linux clipboard for middle-mouse-button paste works for the html preview view, but not for the editor view ?

Plugins (External Graphical Applications) don't work

Gnuplot, ploticus etc. don't work although the required plugins are installed. To test this, go to ExternalGraphicalApplications in wikidpad help. The error appears to be related to file permissions, or attempting to save temporary files to a read only location, eg

Traceback (most recent call last):  File ".../WikidPad-1.9beta15/lib/pwiki/Exporters.py", line 1128, in _processInsertion
    insertionAstNode)
  File ".../WikidPad-1.9beta15/extensions/GnuplotClBridge.py", line 96, in createContent
    dstFullPath = tfs.createTempFile("", ".png", relativeTo="")
  File ".../WikidPad-1.9beta15/lib/pwiki/TempFileSet.py", line 139, in createTempFile
    fullPath = createTempFile(content, suffix, path)
  File ".../WikidPad-1.9beta15/lib/pwiki/TempFileSet.py", line 184, in createTempFile
    fd, fullPath = tempfile.mkstemp(suffix=pathEnc(suffix), dir=pathEnc(path),
  File ".../WikidPad-1.9beta15/lib/pwiki/StringOps.py", line 115, in pathEnc
    return mbcsEnc(s, "replace")[0]
TypeError: coercing to Unicode: need string or buffer, NoneType found

See: http://tech.groups.yahoo.com/group/wikidPad/message/4065 for a workaround

OS detection bug

Note: This bug has been fixed in 11/2006.

File "lib/pwiki/Configuration.py", line 30, in isLinux
return os.uname[0] == "Linux"
TypeError: unsubscriptable object

Issues that seem related to version differences in wxPython

  • Infrequent and non-fatal errors with the tree control (show up on the console)

Other Issues

Source: http://trac.wikidpad2.webfactional.com/wiki/IssuesUnderLinux

Add a custom footer
Add a custom sidebar
Clone this wiki locally