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

List:       kde-usability
Subject:    Re: Stop/Refresh buttons on Konqueror
From:       "Daniel Molina" <dmolina () amnet ! co ! cr>
Date:       2004-09-14 19:16:10
Message-ID: web-4399337 () amnet ! co ! cr
[Download RAW message or body]

Yeah, I remember seeing that option somewhere, but may be 
a choose a poor example for a similar situation to the one 
that Thomas explained before.

About the Stop/Refresh button, how about using some kind 
of progressive transition (fade images, morph images, etc) 
that blocks the button for a second or so, to avoid a Stop 
to Refresh instant switching? So if I'm going to click on 
Stop, instead of button instantly changing to Refresh, it 
blocks itself showing the transition?

Daniel


On Tue, 14 Sep 2004 14:40:43 -0400
  obennett <obennett@hartford.edu> wrote:
>On Tue, 14 Sep 2004 11:52:48 -0600, Aaron Seigo 
><aseigo@kde.org> wrote:
>
>> On September 14, 2004 11:23, Daniel Molina wrote:
>>> I would like to put thius example:  you are writing a
>>> message in Kopete and then all of the sudden a 
>>>background
>>> task you have been perfoming shows a confirmation dialog
>>> for something like "Are you sure you want to delete / 
>>>?",
>>> so when you are going to send you kopete message by
>>> pressing ENTER, the dialog appears and your ENTER just
>>> confirms such operation!!!
>>
>> focus stealing prevention?
>>
>
>Not 'on' by default though and I doubt many users know of 
>this.
>
>-- 
>Using Opera's revolutionary e-mail client: 
>http://www.opera.com/m2/
>_______________________________________________
>kde-usability mailing list
>kde-usability@kde.org
>https://mail.kde.org/mailman/listinfo/kde-usability

_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]