On Thu, Jun 01, 2006 at 05:16:51PM +0200, Tim Janik wrote:
On Wed, 31 May 2006, Kristian Rietveld wrote:
On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote:
I once wrote down how tooltips should behave:
I mostly like the behaviour you described below.
- Tooltips are
On 6/1/06, Tim Janik [EMAIL PROTECTED] wrote:
On Wed, 31 May 2006, Kristian Rietveld wrote:
On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote:
I once wrote down how tooltips should behave:
I mostly like the behaviour you described below.
- Tooltips are too intrusive.
On Tue, Apr 25, 2006 at 03:08:12PM +0200, Soeren Sandmann wrote:
I once wrote down how tooltips should behave:
I mostly like the behaviour you described below.
- Tooltips are too intrusive. The text should be smaller, and
they should to the right of the cursor, and a little
On 4/25/06, Tim Janik [EMAIL PROTECTED] wrote:
i don't think there's a point in implementing grouping unless the above
question has been answered, i.e. we've gotten a resonable usage scenario.
so until that happens, it's probably best to leave groups out of the API spec.
Well, one reason would
Matthias Clasen [EMAIL PROTECTED] writes:
On 4/25/06, Tim Janik [EMAIL PROTECTED] wrote:
i don't think there's a point in implementing grouping unless the above
question has been answered, i.e. we've gotten a resonable usage scenario.
so until that happens, it's probably best to leave
On Tue, 25 Apr 2006, Matthias Clasen wrote:
On 4/25/06, Tim Janik [EMAIL PROTECTED] wrote:
i don't think there's a point in implementing grouping unless the above
question has been answered, i.e. we've gotten a resonable usage scenario.
so until that happens, it's probably best to leave groups
On Tue, 25 Apr 2006, Soeren Sandmann wrote:
Matthias Clasen [EMAIL PROTECTED] writes:
On 4/25/06, Tim Janik [EMAIL PROTECTED] wrote:
i don't think there's a point in implementing grouping unless the above
question has been answered, i.e. we've gotten a resonable usage scenario.
so until that
Tim Janik [EMAIL PROTECTED] writes:
That's because that feature simply doesn't work. Moving the mouse to a
tooltip-less area does not turn off fast mode as it should, regardless
of grouping.
well, given that behaviour is implemented, there's no need for seperate
groups, right?
I am not
On Tue, 25 Apr 2006, Soeren Sandmann wrote:
Tim Janik [EMAIL PROTECTED] writes:
That's because that feature simply doesn't work. Moving the mouse to a
tooltip-less area does not turn off fast mode as it should, regardless
of grouping.
well, given that behaviour is implemented, there's no
I once wrote down how tooltips should behave:
Tooltips:
-
- Tooltips are too intrusive. The text should be smaller, and
they should to the right of the cursor, and a little below
the cursor's center.
|\ ___
On 4/25/06, Tim Janik [EMAIL PROTECTED] wrote:
well, given that behaviour is implemented, there's no need for seperate
groups, right?
The behaviour described by soeren does indeed sound like it may make
tooltips groups unnecessary. I've asked Owen if he can describe the original
motivation for
Tim Janik wrote:
reading your proposal for the first time (both versions of it), i can't
help the
feeling that it seems a bit complicated (with nesting tip areas etc.) at
least
from a widget user perspective.
i'm wondering if a callback based approach wouldn't ease the whole setup
a lot,
so
On Thu, 2006-04-06 at 10:00 +0200, Tim Janik wrote:
On Thu, 6 Apr 2006, Alex Graveley wrote:
I sounds good to me, as long as I can force a tooltip to display on-demand
as
it would if the mouse were hovering over it.
hm, can you please explain the use case for forefully displaying
I sounds good to me, as long as I can force a tooltip to display
on-demand as it would if the mouse were hovering over it.
-Alex
Tim Janik wrote:
On Tue, 14 Mar 2006, Kristian Rietveld wrote:
Hey,
[...]
hi kris.
reading your proposal for the first time (both versions of it), i can't
On Thu, 6 Apr 2006, Alex Graveley wrote:
I sounds good to me, as long as I can force a tooltip to display on-demand as
it would if the mouse were hovering over it.
hm, can you please explain the use case for forefully displaying tooltips?
as opposed to waiting for the usual user
On Thu, 6 Apr 2006, Brijesh wrote:
I can give use case where i need tooltip when i tell it to display
i am gtk on one of the embedded plateform in which we dont have mouse. we
have only keyboard.
so when button gets focused , i want to display tooltip.
how do i do it?
i think that could
Tim Janik wrote:
hm, can you please explain the use case for forefully displaying
tooltips?
as opposed to waiting for the usual user configurable timeout and honour
user settings like display-tooltips = off ?
Such a use case would not necessarily ignore user settings. It could be
a canvas,
On Thu, 6 Apr 2006, Yevgen Muntyan wrote:
Tim Janik wrote:
hm, can you please explain the use case for forefully displaying tooltips?
as opposed to waiting for the usual user configurable timeout and honour
user settings like display-tooltips = off ?
Such a use case would not necessarily
On 6 Apr 2006, at 09:00, Tim Janik wrote:
On Thu, 6 Apr 2006, Alex Graveley wrote:
I sounds good to me, as long as I can force a tooltip to display
on-demand as it would if the mouse were hovering over it.
hm, can you please explain the use case for forefully displaying
tooltips?
as
On 6 Apr 2006, at 15:59, Calum Benson wrote:
Haven't really been following this discussion, but I hope people
are remembering that in gtk, tooltips are supposed to be available
on demand from the keyboard (by pressing Shift-F1),
Sorry, Ctrl+F1...
--
CALUM BENSON, Usability Engineer
20 matches
Mail list logo
