You can subscribe to this list here.
2003 |
Jan
|
Feb
(20) |
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jerry L. <je...@xe...> - 2005-04-01 15:42:31
|
RE: http://kmon.sourceforge.net/ fyi, all the "screenshot" links are broken. It looks like the project is mostly dormant? Thanks, Jerry |
From: <ben...@id...> - 2004-05-22 12:04:35
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: Frank D. <ke...@dr...> - 2003-04-07 11:21:41
|
Op Monday 07 April 2003 00:55, schreef Oleg Kourapov: > I'm using v0.2 (no KDE3 here) of kmon and it works great for me everywhere > except one thing - I'd like it to hide main window by default on startup. > The reason for this is that I put it in autostart and having to dismiss it > every time I login is frustrating. Is it possible to issue some kind of > command line parameter to override default behaviour? > Thanks! hi, i did not provide this functionality, but i think you are right and it should be added to kmon. since a future release will have no more kde2 support , and since its still a bit away in the future, i suggest you to look at dcop: try this (i don't know if it works in kde2, but it works in kde3) use the dcop browser (kdcop) to find kmon, if kmon-mainwindow#1 or something like that shows up, find its method 'hide'. now you can do dcop <kmon ID> kmon-mainwindow#1 hide and kmon will dismiss. (kmon ID will probably be 'kmon' on kde2) however, its possible kde2 does not yet support the mainwindow stuff, then there is another way: dcop <kmon id> qt objects will list all the objects used in kmon. the 'dismiss' button will be one of those, the qmainwindow will be another one. if you are able to locate the dismiss qpushbutton, you can simply dcop <kmon id> qt/<dismiss button name>/activate (to list all methods of a qt object do dcop <kmon id> qt/<object name> ) to activate the dismiss button. the qmainwindow will probably also have a 'hide' method. i know this is a bit messy, but its a workaround until the feature gets added. i hope it works for you. (i cannot really give you the exact object names since i have no running kde2) greetings, frank P.S. in kde2 this trick works with all dcop-aware applications, in recent kde3 almost all kde applications are dcop-aware. -- Frank Dekervel - fra...@st... Mechelsestraat 88 3000 Leuven (Belgium) |
From: Oleg K. <ok...@2s...> - 2003-04-06 22:55:10
|
I'm using v0.2 (no KDE3 here) of kmon and it works great for me everywhere except one thing - I'd like it to hide main window by default on startup. The reason for this is that I put it in autostart and having to dismiss it every time I login is frustrating. Is it possible to issue some kind of command line parameter to override default behaviour? Thanks! -- Oleg "2sheds" Kourapov mailto:ok...@2s... http://www.2sheds.ru ICQ:26308026 |
From: Patrick S. V. <pat...@al...> - 2003-02-25 11:35:44
|
On Tuesday 25 February 2003 05:30, Brett Blackham wrote: > Summary of what I am asking/observed: > Forgive me if I don't remember C++ very well. But is it bad to have the > variable name the same name as a variable passed to the method. In PHP I > think it would just reassign it but I wasn't sure that was okay in C++. forgive me, I seem not to remember c++ at all... ... I thought this might just hide the var. Probably it got hidden bevor assinged! ;-( <snip> > It still wont work but seems to be crashing somewhere else now. this solves this problem... ... there (of course) some problems with the old config settings. > When I changed the name of the KMonListViewItem* from item to myitem (line > numbers 189,190) in mainwindowimpl.cpp I was able to prevent crashes at the > _node->showPopupMenu( p ) in kmonnotifierlistviewitem.cpp But now I get > them at KMonNode::showPopupMenu (QPoint const&) on kmonnode.cpp:144. (see > backtrace) Is it really getting futher? > think so, it now crashes when opening the popup... <snip> > > So I thought I would comment out the _popupMenu->clear(); just to see where > it would get me. (line 144 in KMonNode) > now I am initialising the _popupMenu in the c'tor... > > It just got me to the next line it uses _popupMenu it now crashes while showing the popup... > Patrik, I CC'd you just incase the mailing list still wont let me send. got it twice... thanks anyway! cp |
From: Brett B. <br...@in...> - 2003-02-25 04:31:16
|
Summary of what I am asking/observed: Forgive me if I don't remember C++ very well. But is it bad to have the variable name the same name as a variable passed to the method. In PHP I think it would just reassign it but I wasn't sure that was okay in C++. void MainWindowImpl::showPopup(QListViewItem *item, const QPoint& p , int i) { if (item) { KMonListViewItem* item = dynamic_cast<KMonListViewItem*>(item); item->showPopup(p); } } I changed it to this and it seems to be working better: void MainWindowImpl::showPopup(QListViewItem *item, const QPoint& p , int i) { if (item) { KMonListViewItem* myitem = dynamic_cast<KMonListViewItem*>(item); myitem->showPopup(p); } } It still wont work but seems to be crashing somewhere else now. When I changed the name of the KMonListViewItem* from item to myitem (line numbers 189,190) in mainwindowimpl.cpp I was able to prevent crashes at the _node->showPopupMenu( p ) in kmonnotifierlistviewitem.cpp But now I get them at KMonNode::showPopupMenu (QPoint const&) on kmonnode.cpp:144. (see backtrace) Is it really getting futher? [New Thread 1024 (LWP 13193)] 0x41131909 in wait4 () from /lib/libc.so.6 #0 0x41131909 in wait4 () from /lib/libc.so.6 #1 0x411b59e4 in __DTOR_END__ () from /lib/libc.so.6 #2 0x410630b3 in waitpid () from /lib/libpthread.so.0 #3 0x406a748e in KCrash::defaultCrashHandler(int) () from /usr/kde/3.1/lib/libkdecore.so.4 #4 0x41060e1b in pthread_sighandler () from /lib/libpthread.so.0 #5 <signal handler called> #6 0x40bf3076 in QMenuData::clear() () from /usr/qt/3/lib/libqt-mt.so.3 #7 0x08055794 in KMonNode::showPopupMenu(QPoint const&) (this=0x8115d10, p=@0xfffffe00) at kmonnode.cpp:144 #8 0x080543e9 in KMonListViewItem::showPopup(QPoint const&) (this=0xfffffe00, p=@0xfffffe00) at kmonnotifierlistviewitem.cpp:36 So I thought I would comment out the _popupMenu->clear(); just to see where it would get me. (line 144 in KMonNode) [New Thread 1024 (LWP 15595)] 0x41131909 in wait4 () from /lib/libc.so.6 #0 0x41131909 in wait4 () from /lib/libc.so.6 #1 0x411b59e4 in __DTOR_END__ () from /lib/libc.so.6 #2 0x410630b3 in waitpid () from /lib/libpthread.so.0 #3 0x406a748e in KCrash::defaultCrashHandler(int) () from /usr/kde/3.1/lib/libkdecore.so.4 #4 0x41060e1b in pthread_sighandler () from /lib/libpthread.so.0 #5 <signal handler called> #6 0x40bf25f8 in QMenuData::insertAny(QString const*, QPixmap const*, QPopupMenu*, QIconSet const*, int, int, QWidget*, QCustomMenuItem*) () from /usr/qt/3/lib/libqt-mt.so.3 #7 0x40bf2792 in QMenuData::insertItem(QString const&, QObject const*, char const*, QKeySequence const&, int, int) () from /usr/qt/3/lib/libqt-mt.so.3 #8 0x080557f5 in KMonNode::showPopupMenu(QPoint const&) (this=0x8116c70, p=@0xfffffe00) at kmonnode.cpp:147 #9 0x080543e9 in KMonListViewItem::showPopup(QPoint const&) (this=0xfffffe00, p=@0xfffffe00) at kmonnotifierlistviewitem.cpp:36 It just got me to the next line it uses _popupMenu Patrik, I CC'd you just incase the mailing list still wont let me send. |
From: Frank D. <ke...@dr...> - 2003-02-14 17:48:13
|
Op Friday 14 February 2003 11:11, schreef Patrick S. Vogt: > Hi all, > > so we're basicly back to the old features, except for the systemtray, > check(all|node) and the dcop interface. cool, seems its going fast. > My next step is to implement a KMonNodeList, this should allow to implement > the missing features. > > Soon a KMonConfig should be implented, that reads in the config files and > defines the config widget, I would prefer if each KMonNode subclass handles > those parts it needs. > > One of the things I am not sure about is wether it is better pass the > KMonNode to the KMonNotifier when created or wether one should pass a > KMonNode through the stateChanged signal/slot. well, you mean we could make a 1-1 kmonnotifier<->kmonnode (at creation time) or one notifier for possibly many nodes (at signal/slot). well: - you make 1-1 obligatory with the first solution, and with the second solution, if we decide somewhere in the future 1-1 is better for some cases, we can go for it without changing much. - it doesn't look like we need strict 1-1... so i'd opt for the second one, but i could be wrong.. also, i have to do a talk for my thesis at the end of the month, that means i will not be too active on kmon for the near future. i hope to improve that asap. greetings, frank > > Cheers > Patrick |
From: Patrick S. V. <pat...@al...> - 2003-02-14 10:13:17
|
Hi all, so we're basicly back to the old features, except for the systemtray, check(all|node) and the dcop interface. My next step is to implement a KMonNodeList, this should allow to implement the missing features. Soon a KMonConfig should be implented, that reads in the config files and defines the config widget, I would prefer if each KMonNode subclass handles those parts it needs. One of the things I am not sure about is wether it is better pass the KMonNode to the KMonNotifier when created or wether one should pass a KMonNode through the stateChanged signal/slot. Cheers Patrick |
From: Brett B. <br...@in...> - 2003-02-14 02:59:42
|
Just created a new account and it seems to work. |
From: Brett B. <br...@in...> - 2003-02-14 02:57:58
|
test |
From: Frank D. <ke...@dr...> - 2003-02-13 15:50:57
|
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) |
From: Patrick S. V. <pat...@al...> - 2003-02-13 14:20:27
|
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 |
From: Frank D. <ke...@dr...> - 2003-02-13 13:49:56
|
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 |
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 |
From: Frank D. <ke...@dr...> - 2003-02-13 10:38:34
|
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 |
From: Frank D. <ke...@dr...> - 2003-02-13 10:05:00
|
what list email are you using ? kmo...@li... works fine here frank |
From: Frank D. <ke...@dr...> - 2003-02-12 19:28:18
|
hi! ok, i fixed the Makefile.am so it installs the example monitors, and i fixed the config dialog so it finds those monitors, now it should work out of the box. i put up the tarball here http://www.student.kuleuven.ac.be/~m9823990/kmon-0.3.tar.gz can you try to compile/install it and see if it compiles cleanly and if it works out of the box (it finds the example monitors when there is no pre-existing configfile) if okayed, i'll upload it to sourceforge as a file release and notify freshmeat and apps.kde.com... greetings, frank Op Wednesday 12 February 2003 19:44, schreef Frank Dekervel: > i'll make a kmon 0.3 now |
From: Frank D. <ke...@dr...> - 2003-02-12 18:45:15
|
Op Wednesday 12 February 2003 18:14, schreef Patrick S. Vogt: > > hey, i tought i subscribed you to the mailinglist... ain't it done ? > > i'll subscribe brett too since he became active, see other mails ... > > there no archives... :( no ? so whats this: http://sourceforge.net/mailarchive/forum.php?forum=kmon-devel ? :) > > as for the cvs ml, do you know how to do it? > > > have to go now, will read and reply to your mails in an hour or so > > join #km...@ir... > but i'll leave at 1900 MET i'm there i'll make a kmon 0.3 now greetings, frank |
From: Frank D. <ke...@dr...> - 2003-02-12 17:02:07
|
i cannot send messages with 'subscribe' in the topic to a mailman list can i ? |
From: Patrick S. V. <pat...@al...> - 2003-02-12 17:01:59
|
On Wednesday 12 February 2003 13:14, Frank Dekervel wrote: > hmm yup, but here we have to be careful: > if a server goes down, all the servers that depend on it go down, but if a > service goes down, the server containing that services goes down.. so in > one case, dependancies go up in the tree, other case they go down in the > tree. thats perfectly doable, but it might be confusing. in the gui i would make difference between those two cases... since it makes a big difference of (e.g. a smtp server) wether the smtp service is down or it just cannot send email on because the uplink is down. > > So in this crapy example I would have created a DNS Service Object that > > watched bind and ssh. A Web Service Object that would watch http and > > https. A Router object that would check TCP. And a localhost service > > object that would check ssh. > > > > (The + designates a collapsed tree) > > > > |-Site 1 > > | > > | |- DNS Servers > > | |- Web Servers > > | > > |-Site 2 > > | > > | +-Router > > | > > | |-Web Servers > > aha, i think i now understand patrick better, he said about the same thing > i think (about putting a role in the tree, it makes sense definately, i > just didn't see it). you got it! :-) btw: look at fwbuilder it got a gui like that > hmm and logical grouping of hosts, it seems to make sense too but it'll get > really difficult to get dependancies in the same tree. i'd like to have the since such trees might become infinit recursiv, we must give some attention while checking subnodes, i.e. a trigger probably should not descend the tree more than one or to levels or even better detect recusion and abort. > dependancies directly visible, but maybe it ain't needed and we just should > do something right-mouse-button properties, dependancies, drag a something > here to make this dependant on that something or so we should definitivly have RMB properties and give some attention onto how the subitems open. > > * As far as creating the Service object I figure we would have a place > > to add the mon scripts. It would just list them all. > > * Another area to create/edit the Service Objects see attached file. We > > could also add the action to take if failed here. > > * When creating a host you just bind it to a Service Object. I haven't > > thought of a way to group the servers in a tree but it should be in this > > dialog. If we don't put the action to take if failed at the Service > > Object level we would need to put it here. > > > > If my crazy ideas don't make sense and you would like more screen shots > > to get a better picture let me know and I'll quickly create you some. > > well i think it makes sense :) but 'when creating ...' don't you mean you > create a host and then add some services and/or roles ? you should be able to do nearly anything, copy a host (and change the name), move or copy a service/role from one node to an other. > > Oh, we might want to also have each server keep track of its own logs and > > maybe even have a history of them on file so admins can get an idea of > > total uptime. I would recomend looking at having a DB handle that. cool idea, we could consider to have a KMonLog object structure... > > I will try to think of a way to incorporate your dependency idea. I > > think its a great idea. If we tack dependency we can also make smart > > decision like not have false actions taken. IE Router goes down. Kmon > > might think the router and everything behind it is also down. Then the <dreaming> kmon could initiate rerouting! </dreaming> > > poor admin (me) gets a page for the router a page for the mail server a > > page for the web server . . . . . It should be enough to know the router > > is down. On that same tone if every mon test in a service object fails > > not give pages for 3, 4 or how ever many mon's where attached to that > > service object. One that says all services for your.server.com failed > > should be good. > > well, the separating out the logs can be a good idea, keeping statistics > too, but it would be cool if you could use kmon without a db i think, and i > would not go into too much detail (kmon is still a desktop app, and > desktops happen to be shutdown at night :p) mine is not... ;-) having KMonLog objects allows us to log into a db, save to logs to files or email... hmmm... perhaps KMonAllert would be the name... the gui itself could be just an allert... > > What do you think. > > > > (I would also be happy to quickly qt designer up any proto type ideas you > > or anyone else has. It might be helpful to make sure we are all going > > the same direction) > > i'd change "parameters" into "extra parameters" and add a checkbox > "pass hostname/ip as first parameter" in the dialog you made.. and if not set parent() should be asked for a host/ip... > btw, kmo...@li... is the place to mail to :) hehe... i hope i do not bombard you with emails, frank... cp |
From: Patrick S. V. <pat...@al...> - 2003-02-12 16:35:03
|
On Wednesday 12 February 2003 01:01, Frank Dekervel wrote: > * this should all be possible without confusing the user, i don't think > that'll be easy :) btw, i don't think the exact details of this all are > totally clear yet (maybe patrick already has a clearer image, don't know). yep I have an image, but normaly my images are rather for the adv user than for the luser... ... but having a adv user option might be a good idea anyway. > another idea is getting rid of the awful config dialog (its confusing and > buggy now) and doing everything in the main GUI (there will be a main tool > bar with buttons like 'new host/...' , 'edit' , 'remove' 'disable' and so > on) or even drag'n drop items > P.S. i put a tag (not branch) on current cvs (BEFORE_REWRITE_TAG) maybe we > could put out a small kmon 0.3 maintenance with the fixed extinfo and the > rmb, there is no official kde3.1 release neither, and so we have something > before the rewrite starts ?? ha, i should read _all_ email first... yeah, lets do a 0.3 release and have our monitors installed to, so kmon can start working without hacking. > P.P.S you maybe want to join the just-created kmon-devel, see the lists > page on our project or mail 'help' to > kmo...@li..... how is on this list? shouldn't you put all former devels there? i've created an #kmon channel at irc.kde.org and a kmon-cvs mailing list, but I still have to figure out how to echo cvs logs to the ml cp |
From: Patrick S. V. <pat...@al...> - 2003-02-12 15:48:54
|
On Tuesday 11 February 2003 18:39, you wrote: > i messed out cvs a bit, and i updated some .cvsignore files, so after the > next cvs up -d you might want to run make -f Makefile.cvs. if that doesn't > work well, we'll try the next version of the kde admin dir. cool! > i also moved the kmon homepage to sf, i updated all the links (i think) the > downloads are still hosted on my student account untill we make an actual > sourceforge-file-release would be nice to do a 0.3 release with the new tray on sf now. start coding on the new structure and make a 0.4 release including hosts, a 0.5 with roles and ... > ok, enough non-coding stuff for now, as soon as you commit your base class, > we can divide work a bit .. ok ? (or maybe already now ?) atm I am ripping the timing stuff out of monitor into KMonNode and the GUI stuff into (not yet started, but it's the next step) KMonListItem. it's not compiling atm so i'll do a RELEASE_0_3 branch and then commit to HEAD. anyone wants to make the 0.3 sf release? cheers Patrick |
From: Frank D. <ke...@dr...> - 2003-02-12 12:15:35
|
hello, > I was thinking the same thing. How I was thinking to approach the problem > would be to set up everything like objects. You could have a Web Server > Object that would watch http,https,ssh or what ever someone might have on a > web server. You could create your own service objects to meet your own > needs. (My old job had a Mail server that also did DNS) well, that was what we meant with 'roles', a server can have several roles... > Once you have created your service object you could then assign that object > to a server. Then group the servers such that all the DNS servers could be > shown in a summary (collapsable tree). If we keep it flexable enough > admins could create the trees however they want. So they could group > things logical, by location or both. hmm yup, but here we have to be careful: if a server goes down, all the servers that depend on it go down, but if a service goes down, the server containing that services goes down.. so in one case, dependancies go up in the tree, other case they go down in the tree. thats perfectly doable, but it might be confusing. > So in this crapy example I would have created a DNS Service Object that > watched bind and ssh. A Web Service Object that would watch http and > https. A Router object that would check TCP. And a localhost service object > that would check ssh. > > (The + designates a collapsed tree) > > |-Site 1 > | > | |- DNS Servers > | | +-DNS Server1 > | | +-DNS Server2 > | | > | |- Web Servers > | | > | |-Web Server1 > | | > | |-http > | |-https > | > |-Site 2 > | > | |-DNS Servers > | | > | | |-DNS Server3 > | | | > | | | |-bind > | | | |-ssh > | | > | | +-DNS Server4 > | > | +-Router > | > | |-Web Servers > | > | +-Web Server2 > | +-Web Server3 aha, i think i now understand patrick better, he said about the same thing i think (about putting a role in the tree, it makes sense definately, i just didn't see it). hmm and logical grouping of hosts, it seems to make sense too but it'll get really difficult to get dependancies in the same tree. i'd like to have the dependancies directly visible, but maybe it ain't needed and we just should do something right-mouse-button properties, dependancies, drag a something here to make this dependant on that something or so > +-Site 3 > > |-Localhost > | > |-ssh > > --You could collapse the whole tree to just show a "summary" -- > > > +-Site 1 > > +-Site 2 > > +-Site 3 > > +-Localhost > > > * As far as creating the Service object I figure we would have a place to > add the mon scripts. It would just list them all. > * Another area to create/edit the Service Objects see attached file. We > could also add the action to take if failed here. > * When creating a host you just bind it to a Service Object. I haven't > thought of a way to group the servers in a tree but it should be in this > dialog. If we don't put the action to take if failed at the Service Object > level we would need to put it here. > > If my crazy ideas don't make sense and you would like more screen shots to > get a better picture let me know and I'll quickly create you some. well i think it makes sense :) but 'when creating ...' don't you mean you create a host and then add some services and/or roles ? > Oh, we might want to also have each server keep track of its own logs and > maybe even have a history of them on file so admins can get an idea of > total uptime. I would recomend looking at having a DB handle that. > > I will try to think of a way to incorporate your dependency idea. I think > its a great idea. If we tack dependency we can also make smart decision > like not have false actions taken. IE Router goes down. Kmon might think > the router and everything behind it is also down. Then the poor admin (me) > gets a page for the router a page for the mail server a page for the web > server . . . . . It should be enough to know the router is down. On that > same tone if every mon test in a service object fails not give pages for 3, > 4 or how ever many mon's where attached to that service object. One that > says all services for your.server.com failed should be good. well, the separating out the logs can be a good idea, keeping statistics too, but it would be cool if you could use kmon without a db i think, and i would not go into too much detail (kmon is still a desktop app, and desktops happen to be shutdown at night :p) > What do you think. > > (I would also be happy to quickly qt designer up any proto type ideas you > or anyone else has. It might be helpful to make sure we are all going the > same direction) i'd change "parameters" into "extra parameters" and add a checkbox "pass hostname/ip as first parameter" in the dialog you made.. btw, kmo...@li... is the place to mail to :) greetings, frank |
From: Frank D. <ke...@dr...> - 2003-02-12 00:02:45
|
Op Tuesday 11 February 2003 23:33, schreef u: > TODO. I found the TODO, I swear I looked before I sent that last email. > Guess I was in the wrong directory. I think I'll start off by changing > logThis to logExtended (To get familuar with the code again) Then I'll try > to group hosts. I would also like to have some default templates like web > servers that would check http https ssh without having to add them each > yourself. hi !! (aha you're back) well, this happent in the mean time: - patrick s. vogt joined 2 days ago. kmon wasn't really alive before he joined, i did not do any work on kmon between your patch (extinfo right ?) and before yesterday.. - herber hraeber sent a german translation and build system fixes - patrick implemented kmonsystemtray.* stuff and fixed some other stuff - and i started working on kmon again today (i fixed your extinfo patch, it works okay now) and now we were thinking about a redesign of some parts of kmon, the idea is we want a hierarchic structure instead of a simple list... * a 'host' has several roles - eg mailserver, webserver,... - , * that implies several monitors (http ping, ...) ... another possible abstraction is 'services' * a host has several dependant hosts (eg mailserver depends on router, because if router is down, mailserver will not be reachable) just like the original mon * this should all be possible without confusing the user, i don't think that'll be easy :) btw, i don't think the exact details of this all are totally clear yet (maybe patrick already has a clearer image, don't know). another idea is getting rid of the awful config dialog (its confusing and buggy now) and doing everything in the main GUI (there will be a main tool bar with buttons like 'new host/...' , 'edit' , 'remove' 'disable' and so on) btw, about the download links: aargh.. i'll fix them ASAP. there is more stuff on the page that ain't relevant anymore, will look into it and btw, as a belgian i don't know anyting about employment in utah but i hope you'll find a solution soon :) greetings, frank P.S. i put a tag (not branch) on current cvs (BEFORE_REWRITE_TAG) maybe we could put out a small kmon 0.3 maintenance with the fixed extinfo and the rmb, there is no official kde3.1 release neither, and so we have something before the rewrite starts ?? P.P.S you maybe want to join the just-created kmon-devel, see the lists page on our project or mail 'help' to kmo...@li..... |