You are not logged in.
yesterday i had a discussion with a friend about why it is not possible to start/stop daemons with one click with the mouse in archlinux... so out of curiosity i decided to write a frontend for starting/stopping daemons in arch.
the result after about one hour of playing around with pygtk (especially with positioning buttons ), i have now a working frontend.... and the funny thing is, that i started to like it --- of course with command line you are easier, have all functions that exist for daemons and so on, but single click for start/stop IS really cool.
name of the programm: evocation
latest release: 0.0.1 - first release ever
state of the programm: usable for starting / stopping daemons, no other features included (yet)
url: http://daperi.home.solnet.ch/linux/arch … index.html
if you have any suggestions or code-cleanup or other usefull enhancements, feel free to email me
The impossible missions are the only ones which succeed.
Offline
Instead of buttons, how about a checkbox, that when it is checked or unchecked, you fire off the start/stop action.
That might clean up the display...instead of having all those randomly sized buttons.
Just a thought though..
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
Instead of buttons, how about a checkbox, that when it is checked or unchecked, you fire off the start/stop action.
That might clean up the display...instead of having all those randomly sized buttons.Just a thought though..
they can be forced to look the same, but then, the window will be much more wide in this constellation, because all buttons will be the size of the longest one and that is (for me) "jack-audio-connection-kit"
table = gtk.Table(rows=1, columns=1, homogeneous=False)
just put the homogenous to True and all buttons should have the same size
The impossible missions are the only ones which succeed.
Offline
I see Cactus's point and I'm almost agreeing with him, other than for the fact that people's expectations of checkboxes are not the same as buttons. Buttons "do" things, checkboxes select things.
I do find the interface awkward though - no disrespect. I'd opt for a top to bottom approach, i.e., the daemons are in a single column. Next to the daemon name, I'd have two buttons: "start" and "stop". If the daemon is already started, then "start" is greyed out, and vice versa.
Just my 2p.
Offline
arooaroo ++
"Be conservative in what you send; be liberal in what you accept." -- Postel's Law
"tacos" -- Cactus' Law
"t̥͍͎̪̪͗a̴̻̩͈͚ͨc̠o̩̙͈ͫͅs͙͎̙͊ ͔͇̫̜t͎̳̀a̜̞̗ͩc̗͍͚o̲̯̿s̖̣̤̙͌ ̖̜̈ț̰̫͓ạ̪͖̳c̲͎͕̰̯̃̈o͉ͅs̪ͪ ̜̻̖̜͕" -- -̖͚̫̙̓-̺̠͇ͤ̃ ̜̪̜ͯZ͔̗̭̞ͪA̝͈̙͖̩L͉̠̺͓G̙̞̦͖O̳̗͍
Offline
I would like to see a modular Arch Linux control panel one of these days.
Offline
neat stuff. maybe you could do both layout suggestions and see what people think. i see benefits from both styles.
Offline
How about arooaroos suggestion, but with only one button that offers the only possible task (stop if its running, and start if its not).
And to make it clear which daemons are running I would like to see colors on the text(green for running and red for not running) and options for sorting it by "state" (running / not running), and by name.
Offline
in fact, the widget was the most problematic writing this.
i see your point (cactus and arooaroo).
the checkboxes idea is possible (and once i find some time i will modify it to use checkboxes to see how it looks like).
the one column idea is not what i wanted to have - having about 80 daemons installed, one column is too long to be displayed in the window and it becomes scrollable... but i wanted one-click-one-control thing (without scrolling and all this things for long - because with 80 buttons, the thing becomes a very long column to be scrolled)... there must be all daemons visible at once and by clicking somewhere, you must be able to start/stop them - that's the original idea.
the idea with multiple buttons is a really great one.... i wanted to grep the daemon scripts for options and then include all of them (e.g. the mpd daemon has the option to "update-db" or "create-db" that is not covered yet), but there is not enough space to place them, if they should be visible at once. --- an idea that comes to my mind right now is to have a menu opening, if a button is clicked and this contains all available options of a certain daemon... but i don't know yet, if this is possible with pygtk (i know the lib not for very long)
soniX suggestion using colours is a great one ... does anybody know how to do this with toggle buttons in pygtk? ... i originally took the toggle buttons, because they can show the state easily, but if a daemon fails starting or stopping, they in the 0.0.1 version switch state anyway, what is clearly a bug i have to solve somehow.
about sorting them by state: if you enable a daemon, this would mean that buttons will be jumping around to be resorted ... not very clean and can be also a little bit confusing. i choosen sorting by name because the human brain can find things this way faster (especially if all are shown at once)
thanx for the comments and ideas ... next time i work on it, i will check what is possible of them (especially checking the API if a button can trigger a menu to open at this place where the button were or if it is possible to colour text or parts differently easily)
The impossible missions are the only ones which succeed.
Offline
the one column idea is not what i wanted to have - having about 80 daemons installed, one column is too long to be displayed in the window and it becomes scrollable... but i wanted one-click-one-control thing (without scrolling and all this things for long - because with 80 buttons, the thing becomes a very long column to be scrolled)... there must be all daemons visible at once and by clicking somewhere, you must be able to start/stop them - that's the original idea.
But that's the point, there could be 80 buttons all on one screen! I personally don't mind scrolling because if they are in a single column, sorted in alphabetical order, then I would have no difficulties finding a daemon. The left-to-right (over many columns), top-to-bottom, approach is not as easy to search. I just think there's nothing wrong in having less on the screen at one time rather than fitting everything.
Still, it's up to you. It's still an interesting little project.
Offline
dp wrote:the one column idea is not what i wanted to have - having about 80 daemons installed, one column is too long to be displayed in the window and it becomes scrollable... but i wanted one-click-one-control thing (without scrolling and all this things for long - because with 80 buttons, the thing becomes a very long column to be scrolled)... there must be all daemons visible at once and by clicking somewhere, you must be able to start/stop them - that's the original idea.
But that's the point, there could be 80 buttons all on one screen! I personally don't mind scrolling because if they are in a single column, sorted in alphabetical order, then I would have no difficulties finding a daemon. The left-to-right (over many columns), top-to-bottom, approach is not as easy to search. I just think there's nothing wrong in having less on the screen at one time rather than fitting everything.
Still, it's up to you. It's still an interesting little project.
i just measured how long it takes me to read a multicolumn list and a single column list that is alphabetically sorted. you are right, the jumps from right to left take more time than scrolling. neurologically speaking, that's very interesting because i meant that scrolling takes more time than the jumping with eyes that is done everytime we read something... not so with lists, what makes the single-column variant more attractive!
thanx to making me measure times and find this out (btw i have now another argument in the discussion that started this little project against all-buttons-on-screen 8) )
The impossible missions are the only ones which succeed.
Offline
Our eyes are crazy! Although we are very used to reading horizontally (left-to-right for most languages), there is a cognitive limit of around 66 letters. Any more, then the text becomes more difficult to read. So, look at your textbooks and novels and count the letters. Notice how newspaper columns are even smaller - this makes it easier to keep track of where you're up to, even on a busy bus or train. Now, look at your word processed document, it's around 100 letters. This is why Word documents are (subconsciously) less attractive than, say a Latex document, which follows tried and testing typesetting rules.
So, it is important to keep the amount of (horizontal) information to a confortable limit. (This is why tables with many columns become a blur also)
Offline
You should look into using a Treeview wiget for this instead of all the buttons, with a checkbox to the left and a button to restart to the right.
Offline
You should look into using a Treeview wiget for this instead of all the buttons, with a checkbox to the left and a button to restart to the right.
Personally, I'd do a layout like this (my ascii drawing skills blow my mind):
+-----------------------------------------------------------------------+
| daemons | Archlinux 'network' daemon |
| +alsa |------------------------------------------------------|
| +[NETWORK] | [x] Running |
| +syslog | [Restart] |
| +cron | <misc options here> |
| | |
| | |
| | |
| | |
| | |
+-----------------------------------------------------------------------+
Note left hand pane is a "scrolling region" with either a straight list of a tree based system (the tree would be ideal for possible additions beyond daemons later). The [NETWORK] part simply indicates that item is selected (they can also be color coded for "running" and "not running".
The right hand pane contains a check box for running and not running, and a button to restart it... Other things, such as update-db and things like that can go here too.
Offline
Ummmmm.... :?
/etc/rc.d/foo whatever - what could be easier?
(I know, GUI utilities can be handy. But for things like this?!)
Offline
Thanks for this dp.
I'm getting this error though:
[tyler@eLINUXe ~]$ sudo evocation.py
File "/usr/bin/evocation.py", line 42
self.window = gtk.Window(gtk.WINDOW_TOPLEVEL
Offline
works fine here. It seems that there is a missing parenthesis in your version. On line 42, I have:
self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
Offline
works fine here. It seems that there is a missing parenthesis in your version. On line 42, I have:
self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
yeah, I've got the parenthesis here, just a cut and paste error.
Offline
I used wget to download the file this time instead of firefox and now it works.... :oops:
Offline
SleepyDog wrote:You should look into using a Treeview wiget for this instead of all the buttons, with a checkbox to the left and a button to restart to the right.
Personally, I'd do a layout like this (my ascii drawing skills blow my mind):
+-----------------------------------------------------------------------+ | daemons | Archlinux 'network' daemon | | +alsa |------------------------------------------------------| | +[NETWORK] | [x] Running | | +syslog | [Restart] | | +cron | <misc options here> | | | | | | | | | | | | | | | | +-----------------------------------------------------------------------+
Note left hand pane is a "scrolling region" with either a straight list of a tree based system (the tree would be ideal for possible additions beyond daemons later). The [NETWORK] part simply indicates that item is selected (they can also be color coded for "running" and "not running".
The right hand pane contains a check box for running and not running, and a button to restart it... Other things, such as update-db and things like that can go here too.
Looks like the windows service manager
Offline
I kind of wrote something like this at the beginning of the summer, but I lost interest in it. If anyone wants to take my stuff and run away with it, go for it. It is also in pygtk.
http://bingweb.binghamton.edu/~nzohar1/ … vice/arch/
and a screenshot is here:
Offline
Ummmmm.... :?
/etc/rc.d/foo whatever - what could be easier?
(I know, GUI utilities can be handy. But for things like this?!)
great point ... i was the same opinion before i started to write something to find proof that i was right but it showed that gui's like this CAN be usefull in some situations (e.g. fastly enable httpd and proftpd for short to enable your friend copy some files across and then shut down it again or some similar situations - it's just pressing 2 buttons 2 times ;-) )
thanx to mention my premier opinion
The impossible missions are the only ones which succeed.
Offline
Thanks for this dp.
I'm getting this error though:[tyler@eLINUXe ~]$ sudo evocation.py File "/usr/bin/evocation.py", line 42 self.window = gtk.Window(gtk.WINDOW_TOPLEVEL
python can be very mean with tabs/spaces ... i know ... try not copying but saving the file--- but i see you solved it already
The impossible missions are the only ones which succeed.
Offline
I kind of wrote something like this at the beginning of the summer, but I lost interest in it. If anyone wants to take my stuff and run away with it, go for it. It is also in pygtk.
http://bingweb.binghamton.edu/~nzohar1/ … vice/arch/
and a screenshot is here:
very nice piece of code! as a general gui, it looks really nice. you suit the needs of the people who want a scrollable solution ;-)
The impossible missions are the only ones which succeed.
Offline
evocation 0.0.2 released
changes:
- checkboxes instead of toggle buttons
- element table is less width helping with sorting things
- minor other changes
have a look at the screenshoot here:
The impossible missions are the only ones which succeed.
Offline