Para aqueles que desenvolvem pra linux e windows e o uso de uma maquina virtual não é uma alternativa muito pratica, e tem tempo pra encarar o wine, então essa dica pode ser interessante.
Realmente, rodar uma aplicação no wine pode não ser a opção mais confiavel, mas em muitos casos resolve o problema de ter que trabalhar com dois OS simultaneamente, o que implica o uso de maquinas virtuais, que consomem muito processamento da maquina, mas cada um tem uma opinião e depende de cada caso.
Rodando o lazarus
Varias vezes quando eu instalava o lazarus no wine, não era possivel trabalhar, pois não conseguia abrir os projetos.
Exemplo:
projeto g:\diversos\laztestewin32\linux\rlreportteste.lpi
Ao tentar abrir, o lazarus retorna que o projeto não existe:
E assim ocorre pra qualquer arquivo que tentar abrir.
A primeira solução que me veio a mente foi criar um link simbolico apontando pra pasta requerida, assim:
Considerando G:=/home/teste
cd /home/teste/diversos/laztestewin32/
ln -s linux/ linu
...e pronto, tava resolvido.
O problema é que ao abrir o mesmo arquivo, o lazarus suprimia a ultima letra outra vez, e assim sucessivamente, e tinha que criar um novo link.
Resolvi por a mão na massa e estudar o codigo.
Então criei as seguintes funções:
unit mainwine;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils;
function WineValidFile(filename1:string):string;
function WineValidSaveFile(filename1:string):string;
implementation
function WineValidFile(filename1:string):string;
var
wineFile,wineFile2,winePath,winePath2:string;
wineListChar:TStringlist;
pathLen,charCount:integer;
begin
wineListChar:=TStringlist.Create;
Result:=filename1;
if not SysUtils.FileExists(filename1) then
begin
WinePath:=SysUtils.ExtractFilePath(filename1);
PathLen:=length(WinePath);
WinePath:=copy(WinePath,1,PathLen-1);
wineFile:=SysUtils.ExtractFileName(filename1);
for charCount:=32 to 127 do begin
wineFile2:=WinePath+chr(charCount)+'\'+wineFile;
if fileexists(wineFile2) then begin
Result:=wineFile2;
break;
end;
end;
end;
end;
function WineValidSaveFile(filename1:string):string;
var
wineFile,wineFile2,winePath,winePath2:string;
wineListChar:TStringlist;
pathLen,charCount:integer;
begin
wineListChar:=TStringlist.Create;
Result:=filename1;
if not SysUtils.FileExists(filename1) then
begin
WinePath:=SysUtils.ExtractFilePath(filename1);
PathLen:=length(WinePath);
WinePath:=copy(WinePath,1,PathLen-1);
wineFile:=SysUtils.ExtractFileName(filename1);
for charCount:=32 to 127 do begin
wineFile2:=WinePath+chr(charCount)+'\'+wineFile;
if DirectoryExists(WinePath+chr(charCount)+'\') then
begin
Result:=wineFile2;
break;
end;
end;
end;
end;
end.
Observei que o problema acontece sempre que se usa a classe TOpenDialog e TSaveDialog.
A unit que esta o codigo pra salvar os projetos, packages, etc é a main.pp.
Então, é só incluir essa unit (mainwine) na clausula uses da unit main.pp e chamar essas funções antes de abrir e salvar seus arquivos na ide.
crie uma diretiva USEWINE:
{$DEFINE USEWINE}
Agora implemente nos casos abaixo:
procedure TMainIDE.mnuOpenClicked(Sender: TObject);
...
For I := 0 to OpenDialog.Files.Count-1 do
Begin
AFilename:=CleanAndExpandFilename(OpenDialog.Files.Strings[i]);
{$IFDEF USEWINE}
AFilename:=mainwine.WineValidFile(AFilename);
{$ENDIF}
...
function TMainIDE.DoShowSaveFileAsDialog(AnUnitInfo: TUnitInfo;
var ResourceCode: TCodeBuffer): TModalResult;
...
NewFilename:=ExpandFileNameUTF8(SaveDialog.Filename);
{$IFDEF USEWINE}
NewFilename:=WineValidSaveFile(NewFilename);
{$ENDIF}
...
if ExtractFileExt(NewFilename)='' then begin
NewFilename:=NewFilename+SaveAsFileExt;
{$IFDEF USEWINE}
NewFilename:=WineValidSaveFile(NewFilename);
{$ENDIF}
end;
...
{$IFDEF USEWINE}
NewFilename:=WineValidSaveFile(NewFilename);
{$ENDIF}
NewFilePath:=ExtractFilePath(NewFilename);
...
function TMainIDE.DoShowSaveProjectAsDialog: TModalResult;
...
NewFilename:=ExpandFileNameUTF8(SaveDialog.Filename);
{$IFDEF USEWINE}
NewFilename:=WineValidSaveFile(NewFilename);
{$ENDIF}
if not FilenameIsAbsolute(NewFilename) then
RaiseException('TMainIDE.DoShowSaveProjectAsDialog: buggy ExpandFileNameUTF8');
NewProgramName:=ExtractFileNameOnly(NewFilename);
...
Eu não testei todos os casos, pois para mim desse jeito resolveu grande parte do problema, e o codigo da IDE é muito complexo, e extenso.
Mas fica registrada uma solução para o problema, e aqueles desenvolvedores que colaboram com o projeto e tem mais afinidade com o codigo da unit main.pp e outras units que compoem a IDE, podem apreciar e se for o caso, implementar definitivamente, e assim oferecer mais uma alternativa pro usuario.
Até a proxima.
English version:
Running lazarus under wine
For that they develop for linux and windows and the use of one virtual machine is not an alternative practises, and it has time to try wine, then this tip can be interesting.
Really run an application in wine can not be the option most trustworthy, but in many cases decided the problem to have that to work simultaneously with two OS, what implies the use of virtual machines, that they consume much processing of cpu, but each one has an opinion and depends on each case.
Make lazarus run on wine
Many times when I installed lazarus in wine, he was not possible to work, therefore he did not obtain to open the projects.
Example:
project g:\diversos\laztestewin32\linux\rlreportteste.lpi
When trying to open, lazarus returns that the project does not exist:
E thus occurs pra any archive that to try to open.
The first solution that came me the mind was to create one link symbolic pointing pra required folder, thus:
Considering:
G: =/home/teste
cd /home/teste/diversos/laztestewin32/
ln - s linux/linu
… and ready, it decided.
The problem is that when opening the same archive, lazarus suppressed finishes it letter another time, and thus successively, and had that to create new link.
I decided for the hand in the mass and to study the code.
Then I created following the functions:
Please, sees the unit mainwine.pas above listed
I observed that the problem happens whenever the class TOpenDialog and TSaveDialog is used.
Unit that this the code to save the projects, packages, etc is main.pp.
Then, is alone to include this unit (mainwine) in the uses clause of unit main.pp and to call these functions before opening and saving its archives in IDE.
It creates a directive USEWINE:
{$DEFINE USEWINE}
Now it implements in the cases below:
procedure TMainIDE.mnuOpenClicked(Sender: TObject);
...
For I := 0 to OpenDialog.Files.Count-1 do
Begin
AFilename:=CleanAndExpandFilename(OpenDialog.Files.Strings[i]);
{$IFDEF USEWINE}
AFilename:=mainwine.WineValidFile(AFilename);
{$ENDIF}
...
function TMainIDE.DoShowSaveFileAsDialog(AnUnitInfo: TUnitInfo;
var ResourceCode: TCodeBuffer): TModalResult;
...
NewFilename:=ExpandFileNameUTF8(SaveDialog.Filename);
{$IFDEF USEWINE}
NewFilename:=WineValidSaveFile(NewFilename);
{$ENDIF}
...
if ExtractFileExt(NewFilename)='' then begin
NewFilename:=NewFilename+SaveAsFileExt;
{$IFDEF USEWINE}
NewFilename:=WineValidSaveFile(NewFilename);
{$ENDIF}
end;
...
{$IFDEF USEWINE}
NewFilename:=WineValidSaveFile(NewFilename);
{$ENDIF}
NewFilePath:=ExtractFilePath(NewFilename);
...
function TMainIDE.DoShowSaveProjectAsDialog: TModalResult;
...
NewFilename:=ExpandFileNameUTF8(SaveDialog.Filename);
{$IFDEF USEWINE}
NewFilename:=WineValidSaveFile(NewFilename);
{$ENDIF}
if not FilenameIsAbsolute(NewFilename) then
RaiseException('TMainIDE.DoShowSaveProjectAsDialog: buggy ExpandFileNameUTF8');
NewProgramName:=ExtractFileNameOnly(NewFilename);
...
I did not test all the cases, therefore for me of this skill he decided great part of the problem, and the code of IDE is very complex, and extensive.
But a solution for the problem, and those developers is registered that collaborate with the project and have more affinity with the code of unit main.pp and others units that they make the IDE, can appreciate and it will be the case, to implement definitively, and thus to offer to end user a new alternative.
Until the next one.
Nenhum comentário:
Postar um comentário