Main Page
From Woofgui
Contents |
Woofgui
Definitions
woof: the original commandline application; not our project woofgui: the adapted commandline application; our project gui-app: an independent application that uses woofgui (cf. 2.3)
1. General
1.1 name
It started as woof; on gtk-apps it was woof_ui; now it is woof_gui but on launchpad it is woofgui.
Suggestion:
- I suggest choosing between woofgui or woof_gui
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.
1.2. language
Jabbering in German is fine, but I suggest 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
- contra: actual developers (= us) speak German more easily
2. Usability
2.1 Dependencies
statement: we must as much as possible prevent requiring many dependencies.
2.2 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).
2.3 Gui-application or nautilus-script?
Options:
- only simple nautilus-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 nautilus-script: less clicking;
- pro nautilus-script: no need to select files afterwards; but: we can as easy make n-script for gui-app
- pro nautilus-script: easier to select dirs (which woof can tar).
- contra nautilus-script: woofgui not usable without nautilus, whereas woof is.
- contra nautilus-script: no option to set variables
- pro guiapp: 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.
2.4 Cancelling
We should maybe offer cancel-option also after woof has started, e.g. when connecting ip-adress is not the intended receiver and / or not trusted.
2.5 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
2.6 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.
3. Programming
3.1 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.
3.2 python
should code be updated? We should check what has changed in python since woof was written; what commands are deprecated etc.
3.3 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?
