Many years ago, way before Benny or Nick or Jannis or Brian had entered the xfce project, we were discussing the name for the gtk-2 filemanager. As some of you may know, the gtk-1 filemanager was called xftree, a modification of Rasca's xtree.
I was the one who was going to do the coding, so I started gathering suggestions about what the filemanager should do. As the suggestions came in, things started to look more and more like what Nautilus users were expecting.
So I suggested xfnautilus and commited that to the CVS repository as the initial name (yes, that was before GIT, even before SVN). For the incredulous:
I'd just grab Nautilus and trim it down. But that did not go down well. Many other users complained that they did not want an trimmed down version of Nautilus and that xfce should have its own filemanager.
Ok. Whatever. So I'll call it xffm and forget about pulling in Nautilus code.
That alternate path is now called Rodent.
Here's some stuff written on the xfce list where, well, judge for yourself the way in which Thunar and Nautilus are referred to in a joint manner.
On Thu, Jun 23, 2011 at 9:20 AM, Nick Schermer <nickschermer@gmail.com> wrote:
> On Thu, Jun 23, 2011 at 12:04 AM, Edscott Wilson Garcia
> <edscott@xfce.org> wrote:
>> El 22/06/11 11:32, Nick Schermer escribi?:
>>
>> On Wed, Jun 22, 2011 at 5:09 PM, Edscott Wilson Garcia <edscott@xfce.org>
>> wrote:
>
>
>
>> Rodent is meant to be fast for the user, not for the stop watch under
>> laboratory conditions.
>>
>> I'll take the time to do some explanations, although I am slow to write.
>> Bear in mind that all references to Nautilus are to Nautilus, not to Thunar.
>
> I appreciate that.
>
>> How long does it take a user to identify a paper in pdf format, when the
>> title is unknown? With Nautilus you have to click and click and click, and
>> then back to the click and click and click.
>
> And how does rodent identify this file you need?
>
>> How long does it take a user to run a command in background? With Nautilus
>> you have to click and click and click and then realize you have to install
>> something extra, restart and then click and click and click before you can
>> type (if you can still remember what you wanted to do by then).
>
> What exactly do you want to run in the background? You mean file
> operations (those run async in another thread in gio) or spawn
> commands (cp/ls/etc)?
>
>> How long does it take a user to customize an application to use when opening
>> a certain type of file? With Nautilus you have to click and click and click,
>> and maybe you'll figure it out.
>>
>> Rodent's idea of being fast is allowing the user to do stuff faster, not
>> microseconds to display a label. Nautilus plays in a totally different ball
>> park. Nautilus wants to appeal the greatest number of potential users, most
>> of which do not know what "command line" means.
>
> Come on, it's not that bad. The difference is that nautilus will store
> the account-wide setting (so all apps using gtk/gio benefit), for
> Rodent you probably have to do it a second time if another application
> wants to open the same mime-type.
>
>> I could go on and on and on. You might say that not all users want skim
>> through dozens of scientific pdf articles, or run simulation programs in the
>> background or use an application other than the officially gnome santioned
>> ones. And you are right. Rodent is not for everybody.
>>
>> More numbers? On initial installation Rodent will not appear as fast as it
>> actually is. On virgin installs, disk and memory caches are empty. Once you
>> are using Rodent in a realistic way (not stress testing under ideal
>> conditions), these caches bring the numbers down significantly.
>
> That's the same for every application.
>
>> CPU usage? Rodent is built around a multithreaded design. CPU speed has
>> reached a plateau and the only way go faster is to do more work in parallel.
>> If you do not have a multicore processor, Rodent's design will make is
>> slower than any other program doing the exact same thing. But multicore
>> processors are here to stay.
>
> Threaded as in spawning processes or in multiple threads in the same instance?
>
>> At my office I have "common Joe" box, and it has 4 cores in the chip. Last
>> time I looked (at least a year ago) AMD was attaching 12 cores to the chip.
>> Does 5% of one, hurt? Not for me. After all, that's one of the reasons why I
>> have a computer, to put it to work.
>
> It just a sign of incorrect coding. It's not about the cpu working.
> but about power consumption: battery life and a greener world.
> Companies like intel try hard to reduce power, if your app does not
> sleep, it nearly impossible to do that.
>
>> The important number here is RES. Considering I have 8GB on this
>> "run-of-the-mill" box, what's 35 MB on the? rodent instance? Answer: tiny.
>> Even firefox does not have me worried. At this time I cannot compare with
>> Nautilus because, well, I don't even have it installed. Why not?
>> Dependencies.
>
> 8GB is not normal. Netbooks have 1gb and _a lot_ of people have less then that.
>
>> What about dependencies? If I do an "emerge -p Nautilus" on this Gentoo box,
>> I would need to install no less than 38 packages before it even considers
>> installing Nautilus. Everything from libsoup to gnome-desktop.? Gvfs brings
>> in 34 packages by itself (practically the gnome desktop). That's too much
>> for me, especially when I compare it to the emerge for Rodent.
>
> I agree on that one, but maybe it's better to choose a more
> competitive file manager to compare with.
>
>> The bottom line is that Rodent is small, fast and powerful. If your
>> definition of small, fast or powerful is different, that's fine too.
>
> I understand what you mean and I'm glad there are file manager around
> like Rodent, good to poke tradition once in a while. But if you say
> it's better you shouldn't only use the negative points of the *other*,
> but also show your workflow, so people can decide for their own if it
> is better for them.
>
> The question how Rodent is better remains a bit vague for me, but
> that's not entirely fair since I know a lot better how Thunar/Nautilus
> work.
>
> Nick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Many years ago, way before Benny or Nick or Jannis or Brian had entered the xfce project, we were discussing the name for the gtk-2 filemanager. As some of you may know, the gtk-1 filemanager was called xftree, a modification of Rasca's xtree.
I was the one who was going to do the coding, so I started gathering suggestions about what the filemanager should do. As the suggestions came in, things started to look more and more like what Nautilus users were expecting.
So I suggested xfnautilus and commited that to the CVS repository as the initial name (yes, that was before GIT, even before SVN). For the incredulous:
http://foo-projects.org/pipermail/xfce4-dev/2002-November/000927.html
I'd just grab Nautilus and trim it down. But that did not go down well. Many other users complained that they did not want an trimmed down version of Nautilus and that xfce should have its own filemanager.
Ok. Whatever. So I'll call it xffm and forget about pulling in Nautilus code.
That alternate path is now called Rodent.
Here's some stuff written on the xfce list where, well, judge for yourself the way in which Thunar and Nautilus are referred to in a joint manner.
On Thu, Jun 23, 2011 at 9:20 AM, Nick Schermer <nickschermer@gmail.com> wrote:
> On Thu, Jun 23, 2011 at 12:04 AM, Edscott Wilson Garcia
> <edscott@xfce.org> wrote:
>> El 22/06/11 11:32, Nick Schermer escribi?:
>>
>> On Wed, Jun 22, 2011 at 5:09 PM, Edscott Wilson Garcia <edscott@xfce.org>
>> wrote:
>
>
>
>> Rodent is meant to be fast for the user, not for the stop watch under
>> laboratory conditions.
>>
>> I'll take the time to do some explanations, although I am slow to write.
>> Bear in mind that all references to Nautilus are to Nautilus, not to Thunar.
>
> I appreciate that.
>
>> How long does it take a user to identify a paper in pdf format, when the
>> title is unknown? With Nautilus you have to click and click and click, and
>> then back to the click and click and click.
>
> And how does rodent identify this file you need?
>
>> How long does it take a user to run a command in background? With Nautilus
>> you have to click and click and click and then realize you have to install
>> something extra, restart and then click and click and click before you can
>> type (if you can still remember what you wanted to do by then).
>
> What exactly do you want to run in the background? You mean file
> operations (those run async in another thread in gio) or spawn
> commands (cp/ls/etc)?
>
>> How long does it take a user to customize an application to use when opening
>> a certain type of file? With Nautilus you have to click and click and click,
>> and maybe you'll figure it out.
>>
>> Rodent's idea of being fast is allowing the user to do stuff faster, not
>> microseconds to display a label. Nautilus plays in a totally different ball
>> park. Nautilus wants to appeal the greatest number of potential users, most
>> of which do not know what "command line" means.
>
> Come on, it's not that bad. The difference is that nautilus will store
> the account-wide setting (so all apps using gtk/gio benefit), for
> Rodent you probably have to do it a second time if another application
> wants to open the same mime-type.
>
>> I could go on and on and on. You might say that not all users want skim
>> through dozens of scientific pdf articles, or run simulation programs in the
>> background or use an application other than the officially gnome santioned
>> ones. And you are right. Rodent is not for everybody.
>>
>> More numbers? On initial installation Rodent will not appear as fast as it
>> actually is. On virgin installs, disk and memory caches are empty. Once you
>> are using Rodent in a realistic way (not stress testing under ideal
>> conditions), these caches bring the numbers down significantly.
>
> That's the same for every application.
>
>> CPU usage? Rodent is built around a multithreaded design. CPU speed has
>> reached a plateau and the only way go faster is to do more work in parallel.
>> If you do not have a multicore processor, Rodent's design will make is
>> slower than any other program doing the exact same thing. But multicore
>> processors are here to stay.
>
> Threaded as in spawning processes or in multiple threads in the same instance?
>
>> At my office I have "common Joe" box, and it has 4 cores in the chip. Last
>> time I looked (at least a year ago) AMD was attaching 12 cores to the chip.
>> Does 5% of one, hurt? Not for me. After all, that's one of the reasons why I
>> have a computer, to put it to work.
>
> It just a sign of incorrect coding. It's not about the cpu working.
> but about power consumption: battery life and a greener world.
> Companies like intel try hard to reduce power, if your app does not
> sleep, it nearly impossible to do that.
>
>> The important number here is RES. Considering I have 8GB on this
>> "run-of-the-mill" box, what's 35 MB on the? rodent instance? Answer: tiny.
>> Even firefox does not have me worried. At this time I cannot compare with
>> Nautilus because, well, I don't even have it installed. Why not?
>> Dependencies.
>
> 8GB is not normal. Netbooks have 1gb and _a lot_ of people have less then that.
>
>> What about dependencies? If I do an "emerge -p Nautilus" on this Gentoo box,
>> I would need to install no less than 38 packages before it even considers
>> installing Nautilus. Everything from libsoup to gnome-desktop.? Gvfs brings
>> in 34 packages by itself (practically the gnome desktop). That's too much
>> for me, especially when I compare it to the emerge for Rodent.
>
> I agree on that one, but maybe it's better to choose a more
> competitive file manager to compare with.
>
>> The bottom line is that Rodent is small, fast and powerful. If your
>> definition of small, fast or powerful is different, that's fine too.
>
> I understand what you mean and I'm glad there are file manager around
> like Rodent, good to poke tradition once in a while. But if you say
> it's better you shouldn't only use the negative points of the *other*,
> but also show your workflow, so people can decide for their own if it
> is better for them.
>
> The question how Rodent is better remains a bit vague for me, but
> that's not entirely fair since I know a lot better how Thunar/Nautilus
> work.
>
> Nick