porting FAR to Linux/Unix platform
madsum
Is there any activities going on towards "porting FAR to Linux/Unix
platform"? If yes, please provide me some link/information about it.
Thanks!
Johannes Rössel
> platform"?
Highly unlikely. Far as well as nearly all plugins are based very
closely on the Windows API. Doing a Linux/UNIX port would basically mean
to do a large rewrite of many parts of the code. As the developers are
currently in another large rewrite of the code (full Unicode support) I
doubt that even plans for such a port will emerge in the near future.
Forking mc to build a more FAR-like experience might be a more sensible way.
Regards,
Johannes
anatoly techtonik
> closely on the Windows API. Doing a Linux/UNIX port would basically mean
> to do a large rewrite of many parts of the code.
into sources, so it is even impossible to look over the major
stoneblocks that should be addressed for decoupling in the first
place. I don't even speak about calculating how long will it take.
> Forking mc to build a more FAR-like experience might be a more sensible way.
can help you too.
--
WBR,
anatoly t.
BH
>> closely on the Windows API. Doing a Linux/UNIX port would basically mean
>> to do a large rewrite of many parts of the code.
>
> That's true. The biggest problem is that FAR architecture is hardcoded
> into sources, so it is even impossible to look over the major
> stoneblocks that should be addressed for decoupling in the first
> place. I don't even speak about calculating how long will it take.
>
>> Forking mc to build a more FAR-like experience might be a more sensible way.
mc development is quite stagnant and mc is not accepting patches from
people much (only very few patches sent to mc developers end up
actually in the source) - I presonally tried to submit to mc some
patches to bring some FAR features to mc, but they were not accepted.
So you'll need probably full fork ...
Disadvantage is that mc in in C, and the code is not very flexible and
have many parts that should be IMHO rewritten from scratch. So maybe
better start from scratch and heavily reuse code from both mc and FAR
where usable and the code fot the part in question is good.
> I've heard that people successfully run FAR under Wine. Perhaps Wine
> can help you too.
Unicode FAR (1.80.0.575) works quite well under recent wine, but there
are things that are not working, like the commandline - if you type
any command at commandline you end up with:
wine: Call from 0x7b845a70 to unimplemented function
KERNEL32.dll.GetConsoleAliasW, aborting
and FAR is terminated. That is with WINE 1.0.1, so perhaps improving
WINE to have full support of all features used by FAR may be easier
way to get FAR working under linux.
Other than that, FAR works fine - though there are minor problems with
some plugins and accelerators in dialog does not work always correctly
(I'll have to test new build, maybe it is fixed in meantime :)
Martin
anatoly techtonik
>>
> Disadvantage is that mc in in C, and the code is not very flexible and
> have many parts that should be IMHO rewritten from scratch. So maybe
> better start from scratch and heavily reuse code from both mc and FAR
> where usable and the code fot the part in question is good.
If there are common parts in architecture that is possible to abstract
in both mc and FAR then the fastest would be to link
platform-dependent C modules with crossplatform Python code. But for
prototyping and console drawing operations from Python - it may
require porting curses binding to windows first.
--
--anatoly t.
Uldis Bojars
>> have many parts that should be IMHO rewritten from scratch. So maybe
>> better start from scratch and heavily reuse code from both mc and FAR
>> where usable and the code fot the part in question is good.
>
> If there are common parts in architecture that is possible to abstract
> in both mc and FAR then the fastest would be to link
> platform-dependent C modules with crossplatform Python code. But for
> prototyping and console drawing operations from Python - it may
> require porting curses binding to windows first.
There is a windows version of curses for Python:
http://adamv.com/dev/python/curses/
Maybe you find it useful.
Uldis
anatoly techtonik
> > platform-dependent C modules with crossplatform Python code. But for
> > prototyping and console drawing operations from Python - it may
> > require porting curses binding to windows first.
>
> There is a windows version of curses for Python:http://adamv.com/dev/python/curses/
>
> Maybe you find it useful.
>
to use PDCurses in win32 version of Python binding. I've successfully
compiled this binding for Python with GCC, but to make it into
official distribution a Visual Studio 2008 project file is needed.
Unfortunately, even express version of Visual Studio 2008 doesn't run
on my win2000.
--
anatoly t.
Mark Sandler
Did anyone consider just building Far using Winelib to make it native
linux executable?
I am using Far (1.7) under wine quite extensively, and i can say
modulo few glitches(*) it works great.
The main glitch it has is running native commands under far is a pain
-- the console output gets piped into
parent window, and not into the far window. But it might be just wine
limitation.
mark