gcmd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gcmd-dev] Fw: midnight commander


From: Pavel Roskin
Subject: Re: [gcmd-dev] Fw: midnight commander
Date: Wed, 15 Mar 2006 15:49:57 -0500

Hello!

On Wed, 2006-03-15 at 22:21 +0200, A. Gordon wrote:
> My two cents about some of the issues raised by Pavel:
> > Begin forwarded message:
> > Subject: Re: midnight commander
> >
> > Just a few impressions from version 1.1.7.
> > <...>
> > It's actually a good idea to use C++ - it's better suited for GUI than
> > plain C.
> While Qt/KDE are natively written in C++, GTK and Gnome are natively written 
> in C.

I think there is no language standard for GNOME.

> There are C++ libraries for GTK/Gnome, but moving Gnome-Commander to C++ 
> is more-or-less rewriting it from scratch.

C++ could be used for new code.

> IMHO C++ is not "better suited" (and neither "less suited") for GUI - it 
> is just a different language.

C++ provides better compile time verification of the code.  Invalid
casts are detected just after they are introduced, not when they are
executed by someone.  In other words, errors made by developers are
found quickly.

> GTK (and to some lesser extent, gnome-commander) is very 
> object-oriented, even if it isn't written in C++.

I know, if you want to write something in C, you can do it.  C is Turing
complete.  And so is Visual Basic.

> > Do you need libtool?  Wouldn't it be better to use convenience
> > non-installable libraries?  Every installable library means having an
> > API, and this can be an impediment for GUI developers.
> >   
> I don't see the problem of installable libraries... who are the "GUI 
> developers" that are impeded by these libraries ?
> If anything - libraries are good - they promote code reuse (for example: 
> the internal viewer library can be used by other projects, and the API 
> is easy to use, with both examples and documentation in the 
> gnome-commander tarball).

Evolution has cross-dependencies between libraries, so it cannot be
linked statically without passing special flags to the linker.  It's a
big mess.  As long as you keep API under control, you should be fine.
But libraries tend to grow, and so is API.

> > Obviously you don't have an embedded terminal.  I think it's a must for
> > a file manager.  
> I speak only for myself here, but I believe that a program needs to one 
> thing, and do it well.
> A File manager is not a terminal program.

Then it should embed an existing terminal in some way.

> There is command line entry box, and you can open a terminal window by 
> pressing SHIFT+ENTER (instead of ENTER).
> Embedding a full terminal window (like in Krusader) is not a top 
> priority in my opinion.
> > "Quick Search" without a shortcut is a joke.  It will never be "quick"
> > is it involves menu navigation.
> >   
> "Quick Search" works by pressing CTRL+ALT+LETTER.

It cannot be discovered by looking at the menu.

> I'm currently working on a version with ALT+LETTER as a quick search 
> trigger.
> 
> > F3 should do something more useful on directories.
> >
> >   
> Agreed.
> Midnight Commander treats F3 (view) as "enter" on directories.
> Krusader simply ignores "view" command on directories.
> Suggestions are welcomed.

Far calculates the directory size.

> > There are random crashes when trying to use SMB.  Please use Valgrind to
> > fix memory problems.
> >   
> 
> If you've found bugs, please help us by submitting bug reports on 
> bugzilla (http://bugzilla.gnome.org/browse.cgi?product=gnome-commander).

I'm more likely to find bugs in programs I'm actually using.

-- 
Regards,
Pavel Roskin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]