[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kopete-devel
Subject:    Re: [kopete-devel] Review Request: This Allows A User To Confirm
From:       "Matt Rogers" <mattr () kde ! org>
Date:       2009-03-25 3:24:06
Message-ID: 20090325032406.28564.26683 () localhost
[Download RAW message or body]



> On 2009-03-22 19:40:27, Matt Rogers wrote:
> > why not just extend setActive instead of creating a new function? Nothing wrong \
> > with the current way, just curiousity on my part. :) 
> > Can you provide screenshots of the new dialog and the notification?
> 
> gja wrote:
> Screenshot is above.
> 
> I had originally thought of modifying setActive, but that didn't work for the \
> following reasons: 1) If I just modify setActive by adding a simple 'if' switch, \
> then we end up with a non-asynchronous nightmare. There will be a message popped up \
> on the screen, and until this message is dismissed (or gets killed), the main loop \
> is blocked. This means kopete will not be able to recieve messages, and is just \
> generally dead. Sadly, this is the fault of KMessageBox. 2) Else I could modify \
> setActive, and add a parameter signifying whether we have gotten user confirmation \
> or not (with SetActive calling itself recursively). This seemed like a waste of \
> time, especially because it would be very difficuly to document what that parameter \
> does. 
> Evaluating these two methods, I found the current way (create the KDialog, and set \
> it up using createKMessageBox, and set up a signal to setActive) the best way to \
> avoid both issues 
> Tejas

Good stuff, thanks for the explanation.

Is there a way that we can make this not a message box? Could either the notification \
area in the kopete application itself or a standard knotification that'll show up \
near the system tray be used here? The message box looks clunky, IMO.

I still think this can be committed as is as long as we go back and review the UI \
later to make it less intrusive. Nice work.


- Matt


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/386/#review561
-----------------------------------------------------------


On 2009-03-23 07:16:26, gja wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/386/
> -----------------------------------------------------------
> 
> (Updated 2009-03-23 07:16:26)
> 
> 
> Review request for Kopete.
> 
> 
> Summary
> -------
> 
> This provides the 'ask' option in auto away.
> 
> Ie, when the user returns to a terminal, it asks 'Do you want to become available \
> again'. 
> If the user ignore the message for some time, it vanishes.
> 
> 
> This addresses bug 73605.
> https://bugs.kde.org/show_bug.cgi?id=73605
> 
> 
> Diffs
> -----
> 
> trunk/KDE/kdenetwork/kopete/kopete/config/behavior/behaviorconfig_away.ui 942341 
> trunk/KDE/kdenetwork/kopete/libkopete/kopetebehaviorsettings.kcfg 942341 
> trunk/KDE/kdenetwork/kopete/libkopete/kopetestatusmanager.h 942341 
> trunk/KDE/kdenetwork/kopete/libkopete/kopetestatusmanager.cpp 942341 
> 
> Diff: http://reviewboard.kde.org/r/386/diff
> 
> 
> Testing
> -------
> 
> It works for the following cases:
> 1) User Ignores the message - message disappears
> 2) User clicks 'no' - no change
> 3) User clics 'yes' - becomes available
> 
> 
> Screenshots
> -----------
> 
> The Screenshot
> http://reviewboard.kde.org/r/386/s/63/
> 
> 
> Thanks,
> 
> gja
> 
> 

_______________________________________________
kopete-devel mailing list
kopete-devel@kde.org
https://mail.kde.org/mailman/listinfo/kopete-devel


[prev in list] [next in list] [prev in thread] [next in thread]