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 |