I had an interesting revelation today regarding button placement and
overall usability concerns. I was using a cross-platform (and custom
GUI) 3D app on my Mac. I typically use it on PC. I kept hitting the
wrong dialog button, because they swapped positions from PC to Mac.
Interestingly, I also
Hi Chipp,
In anycase, I'm not sure dialogs are necessarily an OS specific thing
anymore. I think some people who use multiple OS'es-- and there are
more of these people-- may have a consistent contextual memory of button
placement, rather than preferred OS placement. IOW, they relate
to button
Jacque wrote:
Do Linux apps ever invent their own interface
entirely, or do they tend to stick to one of the various distro
conventions? (Would it matter, for example, if my answer dialog was
bright pink and had its OK and Cancel buttons at the top?)
Cautiously, because I'm not a developer
An age-old challenge in making multi-platform apps is handling the
placement of the default button in dialogs.
On Mac OS the confirmation control is on the right, with the cancel
control on the left. Bruce Tognazzini and others maintain that this
placement is best supported by usability
From: Richard Gaskin [EMAIL PROTECTED]
If not, how can we reconcile this issue if we want to deploy our apps to
either window manager?
Not an ideal solution - but maybe as a last resort - ask the user. If they
are running a Gnome desktop etc they *probably* know this (given that *nix
is
Does the Rev engine provide a way to determine which window manager it's
running under in Linux?
If not, how can we reconcile this issue if we want to deploy our apps to
either window manager?
Consider the environment your users are in, and don't worry about it - just
adopt one style or the
Peter Alcibiades wrote:
The Apple gui design guidelines, or human interface guidelines in general,
well, they were great in the eighties, but time has moved on. At least for
Linux users. Uniform look and feel of apps is simply not a factor for us.
Both the Apple and Microsoft HIGs are
But Richard, my point is a slightly different one. Leave aside what we think
of HIGs - my own reaction to the Gnome guys, unlike yours, is total
incomprehension. But leave this aside.
This isn't really the issue. The issue is, even if you are using Ubuntu, and
are using Gnome, odds are you
Peter Alcibiades wrote:
So I am not suggesting making life easy for yourself particularly. Just,
focus on what will matter to users, and whether it looks like gnome or kde I
don't think is going to be one of these things.
Excuse a newbie question. Do Linux apps ever invent their own
J. Landman Gay wrote:
Do Linux apps ever invent their own interface entirely,
or do they tend to stick to one of the various distro
conventions? (Would it matter, for example, if my answer dialog was
bright pink and had its OK and Cancel buttons at the top?)
Would it matter?
For both
Peter Alcibiades wrote:
The issue is, even if you are using Ubuntu, and are using Gnome, odds
are you are not only using Gnome or gtk apps. You're almost certainly
using KDE apps as well. And probably a few others. Because any linux
distro is going to ship with hundreds of apps, and they are
While I'm sure Bruce has scads of data to back his assertion, I'm not sure
it's such a big deal. I have for years created my own interface layer, and
placed the OK button on the right for my custom created dialogs. I sell
mostly to PC users and I've never had a single complaint about the
, its just not there yet. You
might have to choose an interface guidline you think has more merit and stick
with that for now.
Cheers,
Rishi.
On Wednesday 18 April 2007 02:12, Richard Gaskin wrote:
An age-old challenge in making multi-platform apps is handling the
placement of the default
In my little authorization stack, I've to two fields and two buttons.
(Username, password, Login and Cancel). The Login button has the
default property set to true. The problem is when I tab out of the
password field, it skips over the Login button and makes the Cancel
button the default
On Mar 20, 2007, at 9:48 AM, Len Morgan wrote:
In my little authorization stack, I've to two fields and two
buttons. (Username, password, Login and Cancel). The Login button
has the default property set to true. The problem is when I tab
out of the password field, it skips over the
there may be
a
BZ on this but I wanted to confirm this is a known issue.
If I create a standalone app for OS X using 2.7.3, the default button
comes
out looking like the old Classic (OS9) default button rather than the
new
throbbing blue one. Not to say I wouldn't actually *prefer* the older
I'm probably not searching by the right set of criteria, so there may be a
BZ on this but I wanted to confirm this is a known issue.
If I create a standalone app for OS X using 2.7.3, the default button comes
out looking like the old Classic (OS9) default button rather than the new
throbbing
On 8/31/06 4:40 PM, Dan Shafer [EMAIL PROTECTED] wrote:
I'm probably not searching by the right set of criteria, so there may be a
BZ on this but I wanted to confirm this is a known issue.
If I create a standalone app for OS X using 2.7.3, the default button comes
out looking like the old
be
a
BZ on this but I wanted to confirm this is a known issue.
If I create a standalone app for OS X using 2.7.3, the default button
comes
out looking like the old Classic (OS9) default button rather than the
new
throbbing blue one. Not to say I wouldn't actually *prefer* the older
button
On 9/1/06, Dan Shafer [EMAIL PROTECTED] wrote:
I'm probably not searching by the right set of criteria, so there may be a
BZ on this but I wanted to confirm this is a known issue.
If I create a standalone app for OS X using 2.7.3, the default button comes
out looking like the old Classic (OS9
Dan Shafer wrote:
Thanks, Ken. I knew there was an answer. Three dot-revs into 2.7 and we
still have these kinds of rough edges? Hm
To be fair, the installer was overhauled more recently than that. The
omission is an easy fix, requiring only a couple lines of script, and
they're aware it
I have a client who writes his own Rev code. He wants to change the
Default button on a card as he goes from it to another card and then
comes back.
The UI updates correctly. The button says it's the default in the
prop inspector. But hitting Return or Enter at that card does
On 9/27/05, Dan Shafer [EMAIL PROTECTED] wrote:
I have a client who writes his own Rev code. He wants to change the
Default button on a card as he goes from it to another card and then
comes back.
The UI updates correctly. The button says it's the default in the
prop inspector. But hitting
Sarah
Makes sense, BUT Setting the default of a button in the property
inspector in the IDE works in such a way that it does indeed activate
that button's mouseUp script on return/enter without any scripting on
our part. So the question is why when he changes the default button
the question is why when he changes the default button
from button A to button B in a script, does not hitting Return/Enter
activate Button B's default mouseUp handler. Should work as far as I
can tell. Clearly doesn't.
Is this in Mac or Windows? The reason I ask is that the traversalOn may have
, BUT Setting the default of a button in the property
inspector in the IDE works in such a way that it does indeed activate
that button's mouseUp script on return/enter without any scripting on
our part. So the question is why when he changes the default button
from button A to button B in a script
Richard opined:
A logical progression of this design philosophy would be:
OS X 10.4: the default button becomes an animated loop of a dancing
chicken.
OS X 10.5: The animation is expanded to become a really nifty
five-minute gorgeously produced movie of a large predatory cat hunting
Ray G. Miller wrote:
Our battlecry should be: Death to eye candy!
Or maybe more appropriately:
Celebrate the user's eye candy!
It's all about what the end-user is doing, with the computer, the OS, all
applications. The user's work should dominate everything, visually and
conceptually.
On 11/8/03 1:35 PM, Richard Gaskin wrote:
Throbbing buttons are kinda cool, too bad they can't figure a way to
multitask the things so they don't hog the CPU.
They have a cool appearance, but are arguably counterproductive in actual
use (beyond being a CPU hog).
A default button must
Another thing to consider about the throbbing default button is that
familiarity reduces the distraction. I barely notice the thing anymore.
The content (which is different each time) draws more attention.
regards,
Geoff Canyon
[EMAIL PROTECTED]
On Nov 9, 2003, at 2:49 PM, Scott Rossi wrote
.
As for Jaguar,10.1.x the new theme design gives us additional flexibility and what we
can do is hard code an animated gif that the engine would just for the default button.
Tuviah
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com
Hello Kee,
Date: Fri, 7 Nov 2003 19:24:31 -0800
From: kee nethery [EMAIL PROTECTED]
Subject: Mac OS X default button = 100% CPU usage
I have a standalone stack and people complained that it was hogging all
their CPU cycles.
---
I thought I remembered something abpot this before, so
On 11/8/03 12:07 AM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
As for Jaguar,10.1.x the new theme design gives us additional flexibility and
what we can do is hard code an animated gif that the engine would just for the
default button.
Seems like the results would less than optimal
Ken Norris wrote:
Throbbing buttons are kinda cool, too bad they can't figure a way to
multitask the things so they don't hog the CPU.
They have a cool appearance, but are arguably counterproductive in actual
use (beyond being a CPU hog).
A default button must be visually distinct enough
On Saturday, November 8, 2003, at 01:35 PM, Richard Gaskin wrote:
A logical progression of this design philosophy would be:
OS X 10.4: the default button becomes an animated loop of a dancing
chicken.
OS X 10.5: The animation is expanded to become a really nifty
five-minute
gorgeously
time:
I would prefer this as an added value feature. I can't use that eye
straining distraction in my applications. Please get rid of the
animated blink or at least give us the option to use default buttons
that have normal or familiar colors. Having a default button that gets
its focus from
Hi Richard,
Date: Sat, 08 Nov 2003 13:35:29 -0800
From: Richard Gaskin [EMAIL PROTECTED]
Subject: Re: Mac OS X default button = 100% CPU usage
Ken Norris wrote:
Throbbing buttons are kinda cool, too bad they can't figure a way to
multitask the things so they don't hog the CPU
design gives us additional
flexibility and what we can do is hard code an animated gif that the
engine would just for the default button.
Tuviah, in Jaguar, Mail.app 1.3, the throbbing button in the Save As
dialog uses about 10-15% of CPU on a dual/800Mhz box. Do you think that
represents
I have a standalone stack and people complained that it was hogging all
their CPU cycles. If you ran Activity Monitor, sure enough, whatever
was available, it would utilize. Frequently +60% of the CPU.
I thought it had to do with the libUrl libraries because it was the
only stack with them and
as a default button. If I don't set it as a default button, then
this doesn't occur. How can I prevent this from happening if I set it
as the default button?
___
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use
rather than the
image if I set the
button as a default button. If I don't set it as a
default button, then
this doesn't occur. How can I prevent this from
happening if I set it
as the default button?
Hi Richard,
If my memory serves me well (and sometimes I ought to
fire the lazy
Hi,
As a work-around to the background problem with default buttons on OSX,
I am using the following procedure:
1. My splash stack has a colored image layer on which I have a default
button:
Button data: standard, default = true, 64 wide, 28 high, visible=
true, opaque=false.
2, Created
Using OS 10.2.6, Rev 2.0.1
In development phase, I have a splash window with a default button
(pulsing, no editable fields on card). Have a mouseUp handler which
works fine when clicking on the button, but the default button doesn't
respond to enter or return keys.
When a standalone is made
Sorry for not explaining myself clearly :-)
You will have to make the tabbed button shorter, so that the default
button is not on top of it's striped background. Adjust the height of
the tabbed button so that it is only just big enough to show the tabs
and the blue line underneath (about 30
Le vendredi, 4 juil 2003, à 09:16 Europe/Brussels, Sarah a écrit :
Sorry for not explaining myself clearly :-)
You will have to make the tabbed button shorter, so that the default
button is not on top of it's striped background. Adjust the height of
the tabbed button so that it is only just big
This happened to me when I had a tabbed button which I had extended (to
give the striped background). As long as the default button was on top
of the tabbed button, I got this black border. When I shrunk the tabbed
button away, it went back to normal.
Sarah
On Thursday, July 3, 2003, at 06:46
Hello Sarah
Le vendredi, 4 juil 2003, à 05:24 Europe/Brussels, Sarah a écrit :
This happened to me when I had a tabbed button which I had extended
(to give the striped background). As long as the default button was on
top of the tabbed button, I got this black border. When I shrunk the
tabbed
On Wednesday, July 2, 2003, at 01:42 PM, Yves COPPE wrote:
Hello,
I make a push btn and look at the inspector Basic prop
When I use a btn and ask default btn on OS X
this btn flashes a little to invite the user for clicking : GREAT
BUT
there is a square round the button and when I build my app
BUT
there is a square round the button and when I build my app this square
is black ! NOT GREAT
If the square only appears when you click the button, check to see if the
Focus Border is set to true. If so, set it to false.
Regards,
Howard Bornstein
D E S I G N E Q
Le jeudi, 3 juil 2003, à 04:58 Europe/Brussels, Howard Bornstein a
écrit :
BUT
there is a square round the button and when I build my app this square
is black ! NOT GREAT
If the square only appears when you click the button, check to see if
the
Focus Border is set to true. If so, set it to
--- Yves COPPE [EMAIL PROTECTED] wrote:
Le jeudi, 3 juil 2003, à 04:58 Europe/Brussels,
Howard Bornstein a
écrit :
BUT
there is a square round the button and when I
build my app this square
is black ! NOT GREAT
If the square only appears when you click the
button, check to see
51 matches
Mail list logo
