Leif W spake unto us the following wisdom:
> > They're a terrible interface. They're non-discoverable, and they
> Non-discoverable? Let me use a simple analogy. Say I stick my pens in a=
> under my bed. Does it mean they're non-discoverable? Are they irrefutab=
> undeniably undiscoverable, from now to eternity? Should I throw them awa=
> Or perhaps simply MAKE THEM DISCOVERABLE? A simple "Slash Commands" entr=
> the Online Help page might go a long way, as well as a local /help. Or a=
> they non-discoverable because people want to get rid of them, so make them
> hard to find, so they can use a circular argument to justify removal?
Non-discoverable in and of itself is not necessarily a problem.
Witness the double middle-click on the blist. However,
non-discoverable *and* counterproductive is.
Commands could of course be documented, and probably should be; the
IRC system, at least, has some sort of documentation facility
(although perhaps just a list of commands, I'd have to look ...). I
believe core commands do, as well.
> > potentially cause legitimate input strings to do nonintuitive things.
> > Note particularly the pasting of paths on Unix systems, e.g..
> Just hit space or something, sheesh. ' /path/to/whereever' That is
> incredibly simple.
Simple, unclear, and undesirable. I don't *want* to send ' /path'. I
want to send /path. I'm not sure why this offends you so.
> > For the
> > record, what is so "horrible" about making the "start a command"
> > sequence be something which one would *not* expect to actually type to
> > a buddy?
> Like what? As it is, as soon as we type something that we can't send to a
> user, we introduce the need for another input area that is distinct from
> sending messages to the user or server or client. Now we've got to juggle
> around more windows, or worry about the sizing and positioning of more pa=
> in a window. That's just too clutterred.
If you think about it for one second and give up immediately, yes, it
probably will be too cluttered or poorly implemented. This is,
however, very different from coming up with a better solution. As far
as "like what", various control sequences seem to be the current
likely options; I happened to mention simply using ^/ the first time
this came up (weeks ago), and some people seem to like it. It has
also been suggested that we make "Command entry" a menu item, so that
users can rebind it as they wish by using the Gtk+ editable bindings.
> > My argument is that one does not, and should not, expect most IM
> > services to have commands which start with a /. IRC and SILC are
> > possible exceptions,
> Possible? Are you even thinknig of axing these? Because I already find =
> IRC commands so limited, it's frustrating to use Gaim as an IRC client
> sometimes. I'd like to have the ability to make the custom commands. The
> original post about aliases seemed intriguing. Just because other protoc=
> are lacking, who cares? They're braindead. If both clients are Gaim, th=
> both users experience is enhanced across all protocols. If some braindead
> users don't want any slash commands, or can't figure them out, why should=
> dumb down the client?
Note that we're not talking about axing commands completely, merely
changing the trigger keystroke to a non-printable character. No need
to get any panties in a bunch about missing commands just yet.
> > as IRC has historically had /commands and the
> > SILC official client does, as well. For other services, this is
> > completely unexpected.
> Unexpected can be a pleasant surprise, not always doomed and damned. I w=
> impressed to find some other slashes lurking, to hell with other protocol=
> clients. It's their loss to be braindead. :p
I personally call eating random strings because they happen to start
with a perfectly legitimate character "braindead".
> > (Queue someone mentioning the almost
> > utterly unknown //dice or whatever on AIM, which can *only* be used in
> > AIM chats and is implemented server-side ... that's irrelevant.)
> Never heard of that one, and if it's some proprietary command, lose it, of
> course. So I'd agree on that point.
It's not a Gaim-implemented command, as I stated above.
> > Add to this the fact that NO ONE uses /commands in Gaim.
> Well damn, last time I checked, my name wasn't NO ONE. But when it comes=
> Gaim I've adopted the name EDGE CASE. Every little action I do is shovel=
> off as an edge case, so others can get what they want. Then, maybe it's =
> a matter of folks not speaking up, because they know they'll just be slap=
> down anyways.
Perhaps your actions are all edge cases, I don't know. The point,
however, is that we want to find solutions which accomodate *all*
users in some fashion. In my view, moving commands to a yet readily
available location but *out* of the realm of normal characters one
might use in a conversation is such an accomodation. Not all change
Maybe too many ideas do get slapped down, I don't know ... however, I
do know that if all of the ideas that users suggested were added to
Gaim, it would be a pretty crufty piece of software. I personally
think that Gaim has largely made a lot of very much forward progress
in the years that I have been aware of it, so obviously *some* sort of
features are being accepted and integrated.
> > Sure, there
> > may be a few developers who do, but I think the complete and utter
> > lack of outside feature requests for commands is a testament to the
> > fact that most users do not.
> Or as I say, just they know it will be smacked down so they gave up
> bothering to suggest features anymore as almost everything is
> negatively received, unless it comes from someone who has already
> contributed significant portions. The problem, those who can code at
> that level often fall into a very very narrow spectrum of the
> population, and so have very similar ideas and thought processes.
Contributors are certainly given extra weight, at least by me; this is
a natural phenomenon, and I think a good one. People who have looked
at the code, examined the program, and generall given some thought to
things tend to have clearer insight into the problems at hand.
Regarding ideas and thought processes ... I think it should be obvious
even from simply reading this list (much less following IRC) that the
Gaim developers in fact have very different preferences in terms of
desired Gaim functionality and implementation. In fact, I think the
relatively strict sieve formed by pleasing some quorum of the core
developers has led to a much improved, much more powerful and yet much
simpler Gaim in the time that I have been involved.
> > There are simply not enough control-style
> > actions which one would wish to perform with sufficient regularity to
> > justify being unable to paste a simple filename to a buddy. :-P
> Well, if I had the choice to type a few characters of move the mouse
> around for 5-10 seconds, I'd much rather type the few characters. New
> accounts, buddy lists, privacy, files, account connects... What about
> when there's a libgaim and a console-only version, and there is no
> mouse interface? how else will such things be achieved? Splitting a
> console into yet another window for non-messages or commands will eat
> valuable space.
Again, we're not talking about completely removing the command
interface. Additionally, if there is a console version of Gaim, it
would have the option of handling commands however seemed most
appropriate -- reverting to / might even be its solution. (I would
like to think that even a console program could do better, since so
many have.) Regarding splitting the console, that is of course *one*
possible solution; so would be simply changing a prompt string for the
existing text input. So would be floating some sort of input.
Try to think more generally about finding better solutions, rather
than just attacking changes to the status quo.
> > So, in short ... how is using a non-conflicting keystroke to bring up
> > a command input box (for those users who are convinced that they MUST
> > HAVE a command input box) a bad solution?
> It's terribly confusing and cluttering.
What is confusing? Is it more, or less confusing than having a single
input box with particular different semantics for a certain subset of
strings? If it's cluttering to pop up a second entry, what might a
better option be? (This particular point has been getting a lot of
discussion on IRC.) Answering these questions would go a long way
toward helping to find a solution that pleases both those of us who
wish to return the input box to consistency and predictability, and
those who wish to use the command interface heavily.
> New Gaim slogans:
> - Programmed for the least common denominator.
> - So minimalistic, you need to implement everything with plugins to make =
> usable again.
These are of course hyperbolic and somewhat inaccurate.
The laws that forbid the carrying of arms are laws [that have no remedy
for evils]. They disarm only those who are neither inclined nor
determined to commit crimes.
-- Cesare Beccaria, "On Crimes and Punishments", 1764