Port WAIL to Linux #2
Labels
Milestone
Comments
ghost
assigned 
|
On Linux, an alternative to freezing is to create a Linux distro package[1](e.g. .deb files for Debian or Ubuntu, or .rpm files for Red Hat and SuSE.) |
|
|
|
@kanihal Thanks for the suggestion, Regarding your question, we did a revamp of WAIL in Electron that is available for macOS, Windows, and Linux. It uses a different UI model (collection-based) and contains some different tools (e.g., it interfaces with Headless Chrome for crawling) but might fit your need. Please give it a try, as I do not currently have an estimate for the release of the Linux version of WAIL (this repo). |
|
@machawk1 WAIL in electron works on ubuntu & is easy to use. Nice work. |
machawk1
pushed a commit
that referenced
this issue
Oct 22, 2018
creation of new collection correct fixes #63 #62 #59 service stop start cycles button availability and correctly starts/stops them fixes #52 #34 inject script is copied fixes #60 acronyms and capitalization corrected fixes #61 #51 service termination implemented fixes #42 if crawl is running the ui displays this fact fixes #41 open heritrix job in the web ui action added fixes #38 crawl status accurately reflected when viewed from heritrix section fixes #37 opening of archive location on filesystem on MacOS now has focus fixes #30 event log is implemented fixes #36 documented WAIL menu item in side bar does not do anything if already on the screen fixes #26 monitoring of crawls is no longer hit and miss fixes #55 if canceling the twitter sign in the button to do so again is no longer disabled fixes #58 rewrote ui fixes #56 #53 #47 #45 #44 #20 #19 #49 added screen shot of new interface fixes #2
|
There are a couple of outstanding issues that need to be resolved that are preventing the generation of a build for Linux. In using Ubuntu 18.10, Another issue that the MAKEFILE.sh script is currently tailored to macOS with regard to installation directories. |
|
After manually installing wxPython from source (using the package's produces a This makes we question whether pyinstaller is seeing the wxPython installation to import at the time of building WAIL. |
|
A more fundamental example that should probably be resolved first: import wx
print('hello')...then build the py file with pyinstaller: |
|
https://groups.google.com/forum/#!searchin/wxpython-users/pip$20ubuntu%7Csort:date/wxpython-users/HeI3SK2kXws/489LCruzCwAJ may be a lead in resolving the shared library objects warning. This will require recompilation of wxPython. EDIT: It appears that the Also, this rabbit hole is kind of ridiculous, especially compared to compiling WAIL on macOS and Windows. Also also, the blame on the object lib can be attributed to wxPython and looks to be independent on pyinstaller: |
|
Per https://wxpython.org/pages/downloads/, EDIT: Err, there is no 18.10, trying again with 18.04. And then, I receive a Memory Error from pip. EDIT: Bumping up the memory in the Ubuntu VM from the default to 4 GB and repeating the about with 18.04. This allowed the wxPython to complete without reporting an issue. Running |
|
After building wxPython , building WAIL, and running the binary, a shared object issue still arises at the time of binary execution. |
|
Delegating the Linux build process to a Docker container is seeming pretty appealing at this point, given the necessary duct tape. EDIT: Proposed using Docker in #340. |
|
Per wxWidgets/Phoenix#991, This may be the result of the packaging, as the variable is defined in an external file to WAIL.py. A slightly different issue when running the binary: EDIT: This latter issue likely has to do with Linux root path not being set in WAIL.py, like it is for Windows and Mac. |
1 task
machawk1
added a commit
that referenced
this issue
Mar 13, 2019
machawk1
added a commit
that referenced
this issue
Mar 13, 2019
|
@ibnesayeed We talked about this in-person but I figured I would ask you in a ticket to document efforts. Is there a way (alignment aside #396) to make the Linux version (below 50822e6) using Docker "less ugly" by default? Linux: |
|
I don't necessarily find it ugly. Every desktop environment has its unique style of representing certain UI components. Cross-platform UI libraries can be classified in two categories, those that use a unified look and field across platforms by introducing their own UI styles or providing sufficient customization options (such as Electron-based UIs that allow you to write application using HTML/CSS) and those that give a higher-level abstraction of widgets and components that are then mapped to platform's native UI style. Currently, WAIL-Python is using the latter, so such differences are obvious. That said, if you can experiment with various Linux desktop environments and see if it looks better in one or the other, we can perhaps set the Docker image up with a specific distro and desktop to behave like that. Alternatively, we can use a theme for the desktop environment in question (e.g., https://www.gnome-look.org/p/1013741/ for Mac-like UI in GTK/GNOME) and see if that matches your taste better. Another possibility is to use HTML renderer (which I think is an option in wxWidget) to make it more consistent cross-platform, but it might need more changes in the app itself. |
|
When running the |
machawk1
added a commit
that referenced
this issue
Apr 20, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The question remains: where is the most appropriate location that is system independent where WAIL could reside on a Linux system? C:\WAIL is used for Windows, /Applications/WAIL on MacOS X.
The text was updated successfully, but these errors were encountered: