Main Page
From Woofgui
Contents |
Woofgui
General
Definitions
woof: the original commandline application; not our project
woofgui: the adapted commandline application; our project
gui-app: an possible independent application that uses woofgui
Name
- It started as woof (Web Offer One File); on gtk-apps it was woof_ui; now it is woof_gui but on launchpad it is woofgui
- Names in Launchpad can be altered - Let's not be restricted by this in the beginning of the project
Suggestions:
- Choosing between woofgui or woof_gui
- Adopting a new name reflecting the programs origin, but being fancy enough to stand on its own: Wui (Woof User Interface), Woofer (Web-Offer-One-File-ER), Woomf (Web Offer One (or) Many File(s))... keep ideas coming!
- Let's choose a fancy name indeed! Other option: woosh (woof sharing); woofish (woof file sharing; sender uses woof, receiver fishes file from world wide web).
Grounds:
- pro woof_gui: gives most credit to the original program.
- pro woofgui: prevent trouble with the '_'(underscore) e.g. in the url http://launchpad/~woofgui. On launchpad it is already woofgui
- contra woof_gui / woofgui: Naming a tool that shall be specifically designed to make sharing as easy & hassle-free as possible after an acronym ("GUI") out of the toolbox of advanced users & developers is NOT a smart idea. Let's find a simple, sexy name that might be an acronym, but does not require people to understand it - Just like Woof does!
- "Woofer" is great because it reflects the evolution of "woof" while still clarifying that it's something newer + more awesome! The only problem: If someone searches for the project, they are very likely to find lots of stuff to do with HiFi -> Subwoofer ...
Language
Jabbering in German is fine, but please use English for Launchpad
Grounds:
- pro: other people can easily join
- pro: opensource means as open as it gets, so English is appropriate
- pro: the programming is in English
Usability
Dependencies
statement: we must as much as possible prevent requiring many dependencies.
- Python as a basis will do fine. We can build on the import-structure of Python-modules + we can take external modules and distribute them within our software - So nobody needs to download anything but our tool
Easiness
statement: woofgui should be easy; one main window to rule it all, e.g. with spinbuttons to set -c variable and combobox to set compression method (in case of directory to be woofed).
- KISS-Development: Keep It Simple Stupid
- Speaking of easy: We should definitely start writing an installer-script that will copy the files of our software to the correct places on the user's system. It's quite easily done + prevents a whole world of trouble!
Gui-application or nautilus-script?
Options:
- only simple nautilus-script / konqueror-script which refers to woofgui
- gui-app with window to set file and variables. This would result in two possible nautilusscripts: one to run woofgui directly (like now, but without option to set variables) and one to run file with guiapp.
Present handling: nautilus-script.
Grounds:
- pro naut/konqu-script: less clicking;
- pro naut/konqu-script: no need to select files afterwards; but: we can as easy make n-script for gui-app
- pro naut/konqu-script: easier to select dirs (which woof can tar).
- contra naut/konqu-script: woofgui not usable without nautilus/konqueror, whereas woof is.
- contra naut/konqu-script: no option to set variables
- pro gui-app: no need to control evertything from the python-file we are using now. We can use one window which can stay while woof is activated and runs. Easy opion to cancel woof after it was activated (e.g. when connecting ip is not trusted, or sharing became unnecessary.
Cancelling
We should offer cancel-option also after woof has started, e.g. when connecting ip-adress is not the intended receiver and / or not trusted. Problem: this would require an extra window, since the new notification handling in Jaunty deliberately does not support actions like buttons. We could use an alert box (https://wiki.edubuntu.org/NotificationDesignGuidelines).
URL-providing
Do we use clipboard-feature for url-providing? Present handling: copy to clipboard when 'ok' is pressed.
Options:
- clipboard
- grab-button which stores url in clipboard
- (very advanced) offer buttons which open new mail with urls in message or which open chatmessage to selected buddy (like gnome-do plugin). These should be alternatives to the 'ok' button, because woof has to run in order to generate urls.
Suggestion: use clipboard until maybe we can implement option 3. Grounds:
- pro: less clicking
- pro: user selecting and copying with his mouse can go wrong, e.g. missing first or last characters.
- contra: people may not like messing with their clipboard
Messages like what ip-adress connected and if all finished correctly
How do we handle this?
Present handling: none
Options:
- no message;
- extra popup windows;
- (very advanced) maybe it is possible to create window which shows shell output (like ubuntu update-manager window).
- notifications-bubble
- pro: no annoying popup windows that must be clicked away, and user is notified nonetheless.
Programming
What window-generator?
- Now it is zenity, but is that mainstream enough? And can we tweak it, e.g. with buttons that we can assign our own commands to? Maybe wxwidgets is an alternative, or using xulrunner.
- Zenity is just a notification-framework and was never meant to be used for complex GUIs. We should definitely check out the GUI-frameworks. What has to be considered are maintainability, ease of use, functionality between GTK and QT ... I haven't yet made an informed decision, but what I figured from other projects is that chosing a toolkit for a GUI is - to some extend - a matter of belief rather than a logical choice... We'll see.
Python
- The woof-code should be updated! We should check what has changed in python since woof was written; what commands are deprecated etc. We cut get an advanced Python god/dess to have a quick flyover through the existing code & make remarks as to what needs to be changed - We then document it, research it & fix it one step at a time.
Safety
- We should check how safe woof is. It is the same port that is used (which is fine), but is this port when it is offering a file easily hackable?
- A killer-feature for our software would be if the HTTP-connection could be SSL-encrypted. There's a python-library out there doing the heavy-lifting: [1]. What we need to find out is how much trouble it is for the user to get a SSL-certificate to use. Can we just generate one on the fly, let it be unsigned by official organizations and still get good encryption without hassle?
