Thread: [Kmon-devel] Fwd: Begin with the end in mind

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

what list email are you using ? kmo...@li... works fine 
here

frank

hi,

>I tried to send this to the list but it doesn't look like it was delivered.
>Did you get it or should I try sending it again?

ah , stupid 40kb limit i changed it to no limit.

> 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.
>
> Target users:  Bad/Lazy system admins.
> 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 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.

> 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.

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..

- 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.

- 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 ?

> NewSummary.ui shows proposed changes to the Summary page.
> * Tree view of services

yup

> * 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

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..

greetings,
frank

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

ehlo,

> 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, so the right part of 'servers' tab becomes probably that widget.
the first tab is more or less ok.

the actions tab needs adapting (we will probably work with alert scripts just 
like mon scripts + an option to use knotify - maybe as an always-existing 
"knotify" available action, so the "paging" stuff shouldn't be hardcoded in 
the GUI). 
i'm not sure if its a good idea to split it out to a new widget, it seems i'td 
fit well in the global settings (we shouldn't have a ton of different 
settings menu entries too)

"service objects" hmm, well, we used to call it "roles" :). and my previous 
remarks are valid here (about not doing kmail-filter-dialog gui). we might 
split it out to a separate widget here, but there should be a central entry 
too (configure roles or something), because you don't always have to find an 
instance of a role in your list to configure the role.

"servers", well thats one we will split out since that will be the RMB config 
dialog (or at least part of) when you click on a server.

and another remark: you'd better use the qt designer layout features, because 
now your config dialogs won't work if i configure another fontsize. for a 
(bad :p) example see the old ui files.

and the mainwindow:
the bar with dismiss, exit kmon, i'd like to exchange for an xmlgui toolbar. i 
don't think you can do xmlgui stuff with qt designer, i'll ask on #kde-devel 
once.

> > - 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? ;)

the advantage of this is that we can reuse widgets: eg it makes sense to 
configure a role by right-clicking on a role instance and choose configure 
role, but also to do settings->configure roles and then choose the role.

its a bit like the konqueror settings dialog: you can choose settings->file 
types, or you can edit file types directly from various other places 
(kcontrol, konq in fm mode)

maybe we also should adapt the new-style config-dialog-UI (so no tabs but a 
kind of special listview with all the "tabs" in it, like almost every kde app 
now)

> > 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)

brett probably meant 344 hours :)

> 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

i'm not sure we talk about the same thing here. but a kmonnodelist class is 
fine imo.

ok, i really have to do something for my thesis now..

greetings,
frank

On Thursday 13 February 2003 14:49, Frank Dekervel wrote:
> ehlo,

501 syntactically invalid EHLO argument(s)
:)
Hi Frank,

working with mailservers makes me nutts... :-S

> > 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, so the right part of 'servers' tab becomes probably that widget.
> the first tab is more or less ok.

yep, just take the notification stuff away, then it's probably usefull as 
generice KMonNode config widget.

> the actions tab needs adapting (we will probably work with alert scripts
> just like mon scripts + an option to use knotify - maybe as an
> always-existing "knotify" available action, so the "paging" stuff shouldn't
> be hardcoded in the GUI).

agreed.

> i'm not sure if its a good idea to split it out to a new widget, it seems
> i'td fit well in the global settings (we shouldn't have a ton of different
> settings menu entries too)

since most of the host/service/role stuff is more or less the same for all, it 
should be usefull to be able to define those in a node config widget and add 
aditional widget that config the host/service role...

> "service objects" hmm, well, we used to call it "roles" :). and my previous

we'll have both, services and roles

> remarks are valid here (about not doing kmail-filter-dialog gui). we might
> split it out to a separate widget here, but there should be a central entry
> too (configure roles or something), because you don't always have to find
> an instance of a role in your list to configure the role.

i am thinking about having a 2nd window that shows the config of a node in the 
main tree and changes a litte when the node type changes

> "servers", well thats one we will split out since that will be the RMB
> config dialog (or at least part of) when you click on a server.

the config window can be openend by RMB, menu or alike.

> and another remark: you'd better use the qt designer layout features,
> because now your config dialogs won't work if i configure another fontsize.
> for a (bad :p) example see the old ui files.

do it by hand...
... or use designer and generate h/cpp files and edit those.

> and the mainwindow:
> the bar with dismiss, exit kmon, i'd like to exchange for an xmlgui

cool...

> toolbar. i don't think you can do xmlgui stuff with qt designer, i'll ask
> on #kde-devel once.

forget about designer, most kde devels (i know) code their gui by hand

> > > - 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? ;)
>
> the advantage of this is that we can reuse widgets: eg it makes sense to
> configure a role by right-clicking on a role instance and choose configure

you'll be able to inherit most stuff and add the new features, and the user 
will get a config that looks simular for all nodes

> role, but also to do settings->configure roles and then choose the role.

sure...

> its a bit like the konqueror settings dialog: you can choose settings->file
> types, or you can edit file types directly from various other places
> (kcontrol, konq in fm mode)

have it at many places it a good idea

> maybe we also should adapt the new-style config-dialog-UI (so no tabs but a
> kind of special listview with all the "tabs" in it, like almost every kde
> app now)

yeah, but then we can use the main window (as i was sugesting before) and just 
add a new listview, that contains roles, monitors and notifiers (should we 
call 'em alerts?) that can be used.

when the user clicks on a node in the main window he/she gets all options 
(incl. hostnames and the like) and if the focus is on the new listview then 
some options might be disabled.

> > > 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)
>
> brett probably meant 344 hours :)

hehe...  

> > 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
>
> i'm not sure we talk about the same thing here. but a kmonnodelist class is
> fine imo.

cool, have to code it soon, since the listview concept has to be replaced.

> ok, i really have to do something for my thesis now..

good luck!

cp

Op Thursday 13 February 2003 15:18, schreef Patrick S. Vogt:

> 501 syntactically invalid EHLO argument(s)

it would be nice if we could have an irc chat with all 3 of us. it seems we 
all agree on the fundaments but email discussion goes a bit slow ..

since both patrick and i are in europe we have almost the same day-night 
rythm, breth is in USA so thats something else. can brett maybe say when he's 
available for a chat ?

frank

(ps, irc.kde.org, #kmon-devel)