I have just recently tarted to look at Shoes, after a quick dabble with
Tk and Fox, and I really like its elegant style. However, there seems to
be no menu widgets, either built-in or indeed anywhere on the web that I
can find. This is a curious ommission.
Has anyone done this already? Can anyone point me in the right
direction?
Andy J. wrote:
I have just recently tarted to look at Shoes, after a quick dabble with
Tk and Fox, and I really like its elegant style. However, there seems to
be no menu widgets, either built-in or indeed anywhere on the web that I
can find. This is a curious ommission.Has anyone done this already? Can anyone point me in the right
direction?
Shoes is a challenge to you: Don’t think inside the box. Don’t ask how
to put a
menu between your users and your engine. Think instead about what kind
of new,
beautiful GUI would display and animate your features the best.
(Just don’t try to test-first it;)
Phlip wrote:
Andy J. wrote:
I have just recently tarted to look at Shoes, after a quick dabble with
Tk and Fox, and I really like its elegant style. However, there seems to
be no menu widgets, either built-in or indeed anywhere on the web that I
can find. This is a curious ommission.Shoes is a challenge to you: Don’t think inside the box. Don’t ask how
to put a
menu between your users and your engine. Think instead about what kind
of new,
beautiful GUI would display and animate your features the best.
I prefer to be able to choose when I want to think outside the box.
Menus are a ubiquious part of GUIs; users know how to use them and what
to expect. If they want to save, they already know how to do that in
countless GUI applications across Windows and Mac (and I guess Linux
too). But not for a Ruby Shoes application. There is a good reason why
enus have been a part of GUIs for well over twenty years - they work
very well. I think this is a serious ommission from the toolkit, and it
surprises me that no one else on the web sees it that way.
On 12/09/2008, Andy J. [email protected] wrote:
to put a
menu between your users and your engine. Think instead about what kind
of new,
beautiful GUI would display and animate your features the best.I prefer to be able to choose when I want to think outside the box.
Well, you chose that when you chose Shoes.
Menus are a ubiquious part of GUIs; users know how to use them and what
to expect. If they want to save, they already know how to do that in
countless GUI applications across Windows and Mac (and I guess Linux
too). But not for a Ruby Shoes application. There is a good reason why
enus have been a part of GUIs for well over twenty years - they work
very well. I think this is a serious ommission from the toolkit, and it
surprises me that no one else on the web sees it that way.
And they are consistent hindrance in the user interaction for over
twenty years. They are one of the poorest UI parts in use today.
There are other ways how to present a “Save” feature to the user.
There are bazillions of applications out there that have a “Save”
button on every graphics enabled platform I have seen.
And there are many applications that do not require you to save
anything manually. They update your choices on the fly as you make
them. And if the application is intended for editing complex data it
should have undo history anyway, and you can automatically save that.
If you really feel like you absolutely need a menu there is about a
dozen toolkits you can choose from, just choose the tool that fits
your needs.
Thanks
Michal
Various combatants wrote:
Menus are a ubiquious part of GUIs; users know how to use them and what
to expect.
Menus are a Help system that lets you actually do the helped thing. They
should
also display the keystroke shortcut for an action. But…
There are other ways how to present a “Save” feature to the user.
There are bazillions of applications out there that have a “Save”
button on every graphics enabled platform I have seen.
That’s because the Save concept is itself broken. A user saves to create
a
“checkpoint” they can revert to. If the program actually presented the
Revert
itself, as a kind of Undo, then every action should mirror on the hard
drive,
and the program would be less naive-user hostile.
I was going to disagree at first, but I realize how right you are. We
all know that if a computer language allows you to write bad code, more
people will write bad code and get away with it. Conversely, if people
demand that every visual toolkit contains the same widgets, they will
continue to even if some of the widgets are horrible UI design.
You don’t have to think outside the box, just consider UI elements that
make sense. Menu bars have never made sense. In fact, Microsoft Office
helped make them popular; with the new “ribbon”, they’ve killed off
their original design and forced users to consider using something
different.
Actually, a ribbon isn’t too bad of an idea. Can shoes do selections of
buttons like that?
On 12/09/2008, Phlip [email protected] wrote:
Various combatants wrote:
Menus are a ubiquious part of GUIs; users know how to use them and what
to expect.Menus are a Help system that lets you actually do the helped thing. They
should also display the keystroke shortcut for an action. But…
That one was hard to parse…
Yes, in some applications like the AutoCAD the menu is just an addon
that lists some possible functions or makes them conveniently
available (like the middle button menu). The commands performed using
the menu are logged in the command window and can then be retyped by
the user which tends to be much faster even for people who are not
touch typists.
Unfortunately, most applications that do use menus use them as the
primary place for activating the listed functions. Some are replicated
as keyboard shortcuts or other UI elements but many are not, and the
keyboard shortcuts are rarely configurable.
One notable exception used to be the GIMP - earlier versions of the
program allowed the user to point at a menu item and define a keyboard
shortcut by simply pressing the key combination. Currently you have to
change an option hidden in a very complex dialog to activate this
function.
Thanks
Michal
On Fri, Sep 12, 2008 at 07:54:33PM +0900, Andy J. wrote:
But not for a Ruby Shoes application. There is a good reason why
menus have been a part of GUIs for well over twenty years - they work
very well. I think this is a serious ommission from the toolkit, and it
surprises me that no one else on the web sees it that way.
I think Shoes will have menus before the end of the year. All
arguments aside, my compelling reason for adding menus would be
because OS X insists on giving every app a menu. And it hurts the
app if you can’t customize that menu.
Yeah, I know it probably seems horrific that this isn’t done already.
Shoes just isn’t a “GUI” toolkit. Not like wxWidgets or FOX or QT or
any of those. I want to make it fun and light and easy to use.
Whatever that means. And I just haven’t figured out how to fit
menus into that yet.
_why
On 13 Sep 2008, at 06:26, _why wrote:
app if you can’t customize that menu.
Funnily enough that’s the main reason the lack of menus bugs me, but
given the pace at which Shoes is developing I’ve always thought it
churlish to pass comment
Yeah, I know it probably seems horrific that this isn’t done already.
Shoes just isn’t a “GUI” toolkit. Not like wxWidgets or FOX or QT or
any of those. I want to make it fun and light and easy to use.
Whatever that means. And I just haven’t figured out how to fit
menus into that yet.
One obvious side effect of introducing menus is that you’ll face
pressure to support keyboard accelerators as well, which could
interfere with the current method for handling key presses.
Ellie
raise ArgumentError unless @reality.responds_to? :reason
Can I encourage you to keep a consistent vision for Shoes? I think it’s
easy to make GUI toolkits more complicated than they need to be. I’m
looking forward to the “easiness” of Shoes. 
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs