From: Patrick S. V. <pat...@al...> - 2003-02-13 11:40:54
|
On Thursday 13 February 2003 11:37, Frank Dekervel wrote: > > All my college professors said when doing project development one should > > always begin with the end in mind. So this is what I had in mind. as for me i am not developing for a prof nor for a user... ... what i want is a kde systemtray icon that notifies me of changes in the network. > > Target users: Bad/Lazy system admins. Target user: me (or you of course) if i have to care about lusers i want to get paid... ;-) ... but I would not mind having a checkbox for making the gui less advanced > > I say bad/lazy because if the dude knew what is up he would take the time > > to install nagios (http://www.nagios.org) But since nagios is rather a > > pain in the butt to install I think we have a large target audience. But > > I think we should always keep simple in mind. well nagios is a web interface... i did not try it, but i am not very fond of webinterfaces. (e.g. if networking {or the webserver} on my local machine goes down, i _do_ want an alert not a 404) > well another group of target users might be people like me that have some > souper-monitoring daemon running somewhere on a remote machine but want > very quick feedback/interaction on their desktop when they make > configuration changes or try to solve a problem... that isn't possible with > a webinterface. but indeed right. that's my point too. > > As far as what the end user gets I made two quick .ui to try and show > > what I understand the project to be based on the emails. the main window looks nice and is near to what I had in mind, but this ui is probably rather useless since we should generate the tree automaticly. as for the config dialog, it looks nice and might be usefull, but I'd prefer to have a config widget inside each KMonNode (so it can be displayed when needed, e.g. as popup after a RMB click, or alike) > ok some things: > > - you can leave out the hosts tab, since we won't configure hosts from the > config dialog anymore (at least that was te tought), we would do it a bit > like in karm: there is an (xml gui) toolbar with buttons like "new host/new > group/...", and each host/group has a RMB menu with properties.. it might be a cool idea to have a config widget for hosts too... > - we probably want to avoid the kmail-filter-dialog-like design as much as > possible, because everyone kmon user i know has difficulties with that. > so instead of having a listview + a right pane with properties (like its > now) we better have a listview + new, edit, delete buttons, and a separate > dialog box for the properties. or even a 2nd tree view with available nodes that could be draged and droped. > - seems qt designer doesn't support kdialogbase. well no problem, we just > throw out the buttons (ok/apply/cancel) and make it a widget encapsulated > by a kdialogbase-descendant ? each configuration (tab) should be an idependet widget (am i repeating myself? ;) > > NewSummary.ui shows proposed changes to the Summary page. > > * Tree view of services > > yup i'd like to have subitems like roles, monitors, dependencies inside a host (or more general inside a node) > > * Change uptime to timestamp. I ran kmon for weeks at a time and its > > kind > > of hard to figure out when the last failure was when it says 344:23:12 344 years 23 days 12 hours hmmm, this host was started, ano domini 1659... ... it's ok to have an output simular to uptime(1) > wow you have a big uptime :) i shutdown my computer every night.. > > > * I notice most everyone else is not in the US. Unless your cellphone > > service > > > providers use the same email format to send text messages as they do here > > I don't think anyone else would be interested in the "US only text > > messaging setup" under Actions. ie mailto:801...@mo... > > okay. for alerts we have now a generic class, and i will figure out later > how to use KNotify for alerts (stuff like playing sound, showing (passive) > popup, log to a textfile are all done fine by knotify). another descendant > of the alert would be mon-style alert.d alerts. > > another remark: now you represent dependancies by subnodes in the tree. > that was my original idea too, but we didn't figure out yet what to do here > i think.. i'd propose a KMonNodeList class (simular to the KMonNotifierList...) it can be used to handle to subnodes inside a node and to handle the topnodes. perhaps it would be nice to have a global node list, containing one (and only one) pointer to each node, so check all, check down and check up could be implemented quite easy cp |