Community: Spreading the Two-Panel Paradigm
Jan 19, 2005, 03:15 (0 Talkback[s])
(Other stories by Matej Urbančič)
How to Help Your Business Become an AI Early Adopter
[ Thanks to Matej
Urbancic for this link. ]
Some time ago I wrote about Krusader--the full featured
twin panel file manager for Linux and KDE. After that I started
poking for a GNOME file manager that could live on my non
KDE-distro, since Krusader requires some kde libraries. I found a
lot of candidates to fit the bill.
Some of them looked promising and are worth of a further
attention, but my points about single enthusiasts and dispersed
programming from the first article, got even stronger
I guess that no one can do anything about programmers wanting to
work alone. Some programmers like to fork existing source and
continue anew instead of contributing to original applications.
There's nothing wrong with this, if we put aside the progress that
two people can make over one.
What really got me wondering while reading through blogs,
forums, and news sites was what makes a program a widespread
success and what makes different programmers work together. And I
asked myself when new users will be satisfied with new apps. To
answer these questions, I decided to examine the most successful
projects and articles posted on different Linux news sites.
Let's start with my last question. This one is kind of
rhetorical and the answer is easily provable by looking at software
forums: the user is never satisfied. More users equals more wishes
and the result is a bloated app. Or is it?
Solutions for needed program changes and user-specific requests
can be two different projects. The software developers try to
compensate the users' never-ending desires by using two basic
techniques that seem bloat-safe.
For instance, the developers of the Mozilla Project integrated
"extensions" as the tools for adding extra features that are not
bundled in application itself. The biggest advantage of extensions
is their integrated look and feel of basic GUI and thus the
impression of welded functionality and common development language
that spreads the programming through the community.
The second technique is the integration of a plug-in system,
which is supported by many different products. Total Commander, for
example, took a similar approach with a plug-in system, but it is
more robust and oriented towards combined functionality of
different apps and TC, without compromising the speed and
efficiency and support for different archive, file system, and
lister types. Plug-ins add functionality relying on the main GUI
and have defined action sets, while extensions generally are less
restricted on their actions, and use modified, hidden or optional
Among Linux OFM's, Krusader took on an
interesting script-based user
actions system, which can set specific user actions to quick
shortcut keys or icons. Krusader Krew promises that the most useful
scripts will make it into the next release. They already support
several external packers and some VFS. Packers are mainly
standalone programs called from command-line, while VFS's are
deeply integrated in KDE.
All file managers use plugin systems, but none have tried the
extension approach. For the average user, a plugin does not
describe everything it does, especially if its functions are
numerous, as found in packers, so users are still bound to the
command-line for harder tasks.
Extensions, on the other hand, can be more descriptive and can
take a user-friendly approach.
The main problem with all file managers is specter of
functionality. For example, all Krusader users move and copy their
data, while advanced users also use multi rename tools--but only
gurus will write useractions. An extension system could strip the
main program of useraction GUI and add an easily installable
useractions table for users wanting these features but lacking the
knowledge to write them.
Skeptics can always look at Mozilla extensions to find that
extensions are really doing well.
Let's move to the first question I posed. What makes an
application widespread? First of all, the application must be known
in the Internet world to gain on the critical user mass. Again, we
can learn from the aggressive Spread the word marketing of Mozilla
projects. User mass also increases program developers' mass and
integrated extension or plugins programmers mass.
Secondly, the application must be good and useful--or at least
be promising for the users to start following its development. The
better the application, the more users.
Here I have to mention one little thing that must never be
forgotten: users want to be able to customize everything. By
everything, I mean everything!
This is the developer's problem. Satisfy functionality or
appearance. Even though the appearance is the first and most
noticeable part of a program, lacking functionality usually kills
I also came across the so-called "screenshot test," where a
blogger describes that by looking at the application's screens, one
can get very good feeling for what the program is about, how the
program works, and how good the software actually is. No need to
actually download and compile. In addition, screenshots enhance
instruction, which is very important for new users.
The third aspect to examine is development cycle for the
application. Users treat software that does not evolve as obsolete
and they replace it if an alternative is available. In the open
source world the problem of OFMs is quite the opposite. There are
tons of alternatives, but no leading project. On many software
forums, one can see it getting crowded just before the promised
release is scheduled. Extensions of a program can prolong the
The fourth important aim is platform support. On Linux, this
means desktop independence.
And the last aspect is already mentioned plug-in and extension
To answer what makes programmers work together, I can't give you
an answer. The only thing that I found out to be universal is the
"common goal." To translate this to file managers, one would have
to make developers not think so guru or teach users to become
programmers. There is really a lot of "one"-time contributions or
using code from other open source projects. For the programmer to
stick around and work with the group there must be a common
Krusader Krew grew for five years to join eight contributors
under one roof which demonstrates innovation, quality, and speed.
Some other projects are still, under whole open source sky, managed
by single person.
And what happened with finding that GNOME file manager? Well, I
found three that are still developed and look ready for serious
Commander. The first two are both developed with Kylix 3 Open
For the time being, Krusader plus libs stays on top in my
Developers say that it's better to do it good under one desktop
environment then poorly on many. Agreed! When the program reaches
full maturity, it will probably have enough members to start its
other desktop forks if alternatives fail to follow.
Krusader: File Manager for Almost-Geeks(Dec 01, 2004)