kcron - multiple fixes

Hi all,

I have been ironing out some more kcron bugs - would
appreciate it if
you guys would look over the patch and let me know what you
think. It
does the following ...

(1) fixed statusbar messages (still not working for top drop
down menus!)
(2) remove statusSettingsCallback method - no longer
appropreate
(3) redefined QDialog::accept () {} so OK button does not
automaticly
close task dialogue, greatly improves popup warning flow
(4) redefined QDialog::accept () {} so OK button does not
automaticly
close variable dialogue, greatly improves popup warning
flow
(5) adds check to see if executable is in $PATH if no
absolute path given

In a popup warning it says "Program is not in $PATH.
Please
re-enter.". Is referencing $PATH OK ... or does it
expose too much of
the inner workings of the machine ?

Also I fixed the status bar messages, they work for the
toolbar and
for the right click menu in the main window but not the drop
down menu
from the edit taskbar. The status bar messages are written
with
statusBar()->showMessage(text);, 'text' is being
generated correctly
but it appears that there is a conflict as in this one case
it is not
displayed.

Cheers 

Dave

PS - still say KStatusBar::insertItem does not work as
documented -
but worked around it ;)



-- 

The unavoidable price of reliability is simplicity.

-- C.A.R. Hoare

 
>> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<

On Sunday 10 June 2007, dave selby wrote:
> (2) remove statusSettingsCallback method - no longer
appropreate
> (3) redefined QDialog::accept () {} so OK button does
not automaticly
> close task dialogue, greatly improves popup warning
flow
> (4) redefined QDialog::accept () {} so OK button does
not automaticly
> close variable dialogue, greatly improves popup warning
flow

a successful slotOk closes teh dialog still, through, irght?
one other 
thought: i wonder if it might make sense to show the error
-in- the dialog, 
e.g. using KTitleWidget to do so, rather than popping up Yet
Another 
Dialog(tm) for the user to interact with.

> (5) adds check to see if executable is in $PATH if no
absolute path given

i'd recommend using KStandardDirs::findExe instead of
relying on which and 
system().

> In a popup warning it says "Program is not in
$PATH. Please
> re-enter.". Is referencing $PATH OK ... or does it
expose too much of
> the inner workings of the machine ?

probably enough to just say it's not found?

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1
A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com
)

 
>> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<

On 10/06/07, Aaron J. Seigo <aseigokde.org> wrote:
> On Sunday 10 June 2007, dave selby wrote:
> > (2) remove statusSettingsCallback method - no
longer appropreate
> > (3) redefined QDialog::accept () {} so OK button
does not automaticly
> > close task dialogue, greatly improves popup
warning flow
> > (4) redefined QDialog::accept () {} so OK button
does not automaticly
> > close variable dialogue, greatly improves popup
warning flow
>
> a successful slotOk closes teh dialog still, through,
irght?

Yep - but pre-patch you get a dialog, you dont enter enough
info, you
click OK, you get a popup saying you need to enter x,y,z,
you click OK
and it plus the original dialog closes. ouch

Re-opening the dialog all parameters are defaulted ... grrr


Post-patch you get a dialog, you dont enter enough info, you
click OK,
you get a popup saying you need to enter x,y,z, you click
OK, you are
back in the original dialog with the data you have enterd so
far still
intact.  - seems
abit smoother ....

one other
> thought: i wonder if it might make sense to show the
error -in- the dialog,
> e.g. using KTitleWidget to do so, rather than popping
up Yet Another
> Dialog(tm) for the user to interact with.
>

The problem is the error would only be descoverd when the
user presses
OK, without a popup - isnt there the possibility of a user
not reading
the existing dialog and blindly hitting the OK thinking its
broken ? I
supose it could flash red or something ?

> > (5) adds check to see if executable is in $PATH if
no absolute path given
>
> i'd recommend using KStandardDirs::findExe instead of
relying on which and
> system().

Great idea - did not know it existed. I felt uncomfortable
with 'which' !

>
> > In a popup warning it says "Program is not in
$PATH. Please
> > re-enter.". Is referencing $PATH OK ... or
does it expose too much of
> > the inner workings of the machine ?
>
> probably enough to just say it's not found?

Yep I was wondering - probarbly best to hide the inner
workings -
scares the users !


>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7
2EB1 A7F1 DB43
>
> Full time KDE developer sponsored by Trolltech (http://www.trolltech.com
)
>
>
> >> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<
>
>
>


-- 

The unavoidable price of reliability is simplicity.

-- C.A.R. Hoare
 
>> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<

> one other
> > thought: i wonder if it might make sense to show
the error -in- the dialog,
> > e.g. using KTitleWidget to do so, rather than
popping up Yet Another
> > Dialog(tm) for the user to interact with.
> >

... thinking ... it is possible with the existing kcron
structure for
two popups to happen one after the other over a single
modify task
dialog. ie ...

Please enter the following to schedule the task: ... &
when that is sorted ...
Cannot locate program. Please re-enter. or possibly my new
popup (if
no absolute path given.)

I will try and integrate the popups to make it only one
popup with all
the information in one place - you are eright less popups is
better 

Cheers

Dave
 
>> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<

On Sunday 10 June 2007, dave selby wrote:
> On 10/06/07, Aaron J. Seigo <aseigokde.org> wrote:
> > On Sunday 10 June 2007, dave selby wrote:

> intact.  - seems
abit smoother ....

by far; good call =)

> > thought: i wonder if it might make sense to show
the error -in- the
> > dialog, e.g. using KTitleWidget to do so, rather
than popping up Yet
> > Another Dialog(tm) for the user to interact with.
>
> The problem is the error would only be descoverd when
the user presses
> OK, without a popup - isnt there the possibility of a
user not reading
> the existing dialog and blindly hitting the OK thinking
its broken ? I
> supose it could flash red or something ?

yes, KTitleWidget changes the presentation of the contents
if you use 
ErrorMessage or one of the other critical MessageTypes. it
is quite apparent. 
you can even set an autotimeout and only show the
KTitleWidget when there is 
an error. other dialogs, such as in kopete, are using it in
exactly this way! 
=)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1
A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com
)

 
>> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<

On 10/06/07, Aaron J. Seigo <aseigokde.org> wrote:
> On Sunday 10 June 2007, dave selby wrote:
> > On 10/06/07, Aaron J. Seigo <aseigokde.org> wrote:
> > > On Sunday 10 June 2007, dave selby wrote:
>
> > intact.  - seems
abit smoother ....
>
> by far; good call =)
>
> > > thought: i wonder if it might make sense to
show the error -in- the
> > > dialog, e.g. using KTitleWidget to do so,
rather than popping up Yet
> > > Another Dialog(tm) for the user to interact
with.
> >
> > The problem is the error would only be descoverd
when the user presses
> > OK, without a popup - isnt there the possibility
of a user not reading
> > the existing dialog and blindly hitting the OK
thinking its broken ? I
> > supose it could flash red or something ?
>
> yes, KTitleWidget changes the presentation of the
contents if you use
> ErrorMessage or one of the other critical MessageTypes.
it is quite apparent.
> you can even set an autotimeout and only show the
KTitleWidget when there is
> an error. other dialogs, such as in kopete, are using
it in exactly this way!
> =)
>

Cool ! - will look at kopete & try and re-code it.

Cheers once again

Dave




> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7
2EB1 A7F1 DB43
>
> Full time KDE developer sponsored by Trolltech (http://www.trolltech.com
)
>
>
> >> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<
>
>
>


-- 

The unavoidable price of reliability is simplicity.

-- C.A.R. Hoare
 
>> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<

On 10/06/07, Aaron J. Seigo <aseigokde.org> wrote:
> On Sunday 10 June 2007, dave selby wrote:
> > On 10/06/07, Aaron J. Seigo <aseigokde.org> wrote:
> > > On Sunday 10 June 2007, dave selby wrote:
>
> > intact.  - seems
abit smoother ....
>
> by far; good call =)
>
> > > thought: i wonder if it might make sense to
show the error -in- the
> > > dialog, e.g. using KTitleWidget to do so,
rather than popping up Yet
> > > Another Dialog(tm) for the user to interact
with.
> >
> > The problem is the error would only be descoverd
when the user presses
> > OK, without a popup - isnt there the possibility
of a user not reading
> > the existing dialog and blindly hitting the OK
thinking its broken ? I
> > supose it could flash red or something ?
>
> yes, KTitleWidget changes the presentation of the
contents if you use
> ErrorMessage or one of the other critical MessageTypes.
it is quite apparent.
> you can even set an autotimeout and only show the
KTitleWidget when there is
> an error. other dialogs, such as in kopete, are using
it in exactly this way!
> =)

Hi,

Any other examples ? - compiled kopete but its not
displaying a config
at present. Want to see an example to model kcrons config on
- make it
all look similar 

Cheers

Dave






>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7
2EB1 A7F1 DB43
>
> Full time KDE developer sponsored by Trolltech (http://www.trolltech.com
)
>
>
> >> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<
>
>
>


-- 

The unavoidable price of reliability is simplicity.

-- C.A.R. Hoare
 
>> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<

On Tuesday 12 June 2007, dave selby wrote:
> Any other examples ? - compiled kopete but its not
displaying a config
> at present. Want to see an example to model kcrons
config on - make it
> all look similar 

hmm... not that i know of that are using it in this fashion.
you can look at:

	kdenetwork/kopete/libkopete/ui/avatarselectorwidget.cpp

to see code examples. there are other uses of KTitleWidget
of course. 
lxr.kde.org is good for that.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1
A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com
)

 
>> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<

On 12/06/07, Aaron J. Seigo <aseigokde.org> wrote:
> On Tuesday 12 June 2007, dave selby wrote:
> > Any other examples ? - compiled kopete but its not
displaying a config
> > at present. Want to see an example to model kcrons
config on - make it
> > all look similar 
>
> hmm... not that i know of that are using it in this
fashion. you can look at:
>
>        
kdenetwork/kopete/libkopete/ui/avatarselectorwidget.cpp
>
> to see code examples. there are other uses of
KTitleWidget of course.
> lxr.kde.org is good for that.

Cheers ... never knew about  lxr.kde.org 

Dave



>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7
2EB1 A7F1 DB43
>
> Full time KDE developer sponsored by Trolltech (http://www.trolltech.com
)
>
>
> >> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<
>
>
>


-- 

The unavoidable price of reliability is simplicity.

-- C.A.R. Hoare
 
>> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<