Jeremy Reed and I had this discussion about the menu
configuration, and he posed some good questions. He
also told me how to fix the Click-To-Focus problem
(repeated to help newbie lurkers).
I thought it would be appropriate for the BlackBox ML
to see what we discussed.
Jeremy: I revised it a little from the first email I
sent, to make it easier to read.
CD
==============================================
> make sure you caps lock, scroll lock and num
> lock keys are off.
The num lock was on, I can't believe that was
<messing> it up! Thanks!!
If that was in the docs, I apologize for not RTFM. I
thought I'd scanned through it pretty well.
====================================================
> > I'd like to see the black-box menu file could be
> more
> > configurable by using a real folder structure
> > somewhere on the hard drive, like in Windows.
> > Something like a #include in the menu file, then
> the
> > folder that was #include-ded would be ls-ed and
> then
> > used in the menu. One could drop actual programs,
> > symlinks, documents, whatever, into a logical
> layout
> > and then *boom* have a menu. One could even set
> up a
> > You'd have a menu of what?
For instance, in Windows (I have to keep referring to
that because it's the only thing similar I know), I
have C:\Winnt\Profiles\Administrator\Start
Menu\Subfolders\Shortcuts N' Stuff.lnk and
C:\Winnt\Profiles\All Users\Subfolders\Shortcuts N'
Stuff.lnk
What I would like is, perhaps something like
/home/user/blackbox-menu/subdirectories/symlinks-n-stuff
and
/usr/share/blackbox/blackbox-menu/subdirectories/symlinks-n-stuff
and have BlackBox render both directory trees in a
nice menu.
That way I could EASILY build a menu for all users and
still build myself a nice personal menu, as could my
users.
I understand that special menu commands, such as
[config] and [restart] couldn't be represented, and
that's why I suggest a hybrid system using [include]*
(menu-name) {/directory} in the blackbox-menu file.
*I said #include before, but I thought the [include]
that's already used would be better.
> How would you know if the file should be ran? (Just
> because it is
> executable doesn't mean that it can be ran with no
> command-line arguments;
> and some progarms need a terminal for any input or
> to see results.)
That's true. That's where the hybrid system would
shine; I could specify command-line arguments in the
existing blackbox-menu file, as I already do.
As far as if it is not executable, I don't know. To
fix that would get into heavy Window Manager
territory, with MIME types and whatnot. Perhaps if a
user tries to execute a file with inappropriate
permissions, a warning that the file is not executable
could pop up, perhaps with a quick explaination
"RTFM!" (or, better) "File is not executable! Read
the
BlackBox documentation on creating menus, chapter X."
What happens with the current menu system? What
happens when a menu file is incorrectly formatted, and
a command is specified that doesn't have appropriate
permissions, or needs command line arguments, or needs
a terminal window? Clicking on that menu item shows
nothing. The menu dissapears.
> Or how would it know what to do with other files?
BlackBox probably should assume that every
file/symlink is an [exec] and every subdirectory is a
[submenu]. This is overly presumptuous, but that
happens with the current menu file when a user
specifies a command that doesn't exist, isn't
executable (or is and shouldn't be), or requires a
terminal. The same rules should apply. Or perhaps a
popup box as I mentioned before.
> How does it know how to open certain documents? For
> example:
> $ file column-template.php3
> column-template.php3: exported SGML document text
> $ file -i column-template.php3
> column-template.php3: text/html
> Should it open an SGML file with a text editor? With
> a php interpreter?
> With a SGML browser? Or should it open it with an
> HTML/web browser? Or an
> HTML editor? ...
That gets into MIME types, which the heavy Window
Managers use.
So I'm going back on my suggestion that documents
should be allowed in the menu. As I mentioned above,
any file/symlink should be considered a command. I
say, if the user doesn't know how to RTFM, and if he
puts a document in there and tries to run it, the same
thing should happen as in the command line.
To use your example, if I was to type
"column-template.php3" on the command line, I would
get
"bash: column-template.php3: command not found". If I
put
[exec] (Column-Template.php3) {column-template.php3}
in the blackbox-menu file, it does nothing.
So why change it? The assumption that the file is a
command would work for symlinks and real programs, and
ignore documents.
> Another example: "test.ogg". Currently, my file(1)
> can't determine the
> file type. So is it an Ogg Vorbis audio file? An Ogg
> Squish audio file? An
> Ogg Tarkin video file? Or some other file formatted
> using Ogg layout?
> (And then how do you choose which of many players to
> play the file?)
MIME types can be hairy.
> Figuring out all this is a job for an outside
> application. And it will
> take a lot of configuration.
Yep. Best left up to heavy Window Managers.
> > At the very least, I would like to see a menu
> builder
> > that simply scans a chosen folder and builds the
> menu
> > file that way.
> > It can already do that with style files (using
> [stylesdir] and/or
> [stylesmenu]).
Then we're on the right track! I see what you mean.
When I put a style in the styles directory, it shows
up right away on the menu. Sounds as if it should be
easy. I'd dig right in if I knew how, where, and how
to code.
Anyways, thanks for your input. It's a fantastic
Window Manager and I can't complain at all as it is.
CD
__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/
