Pesquisa para revitalização da HwGUI - Opinem

por **alaminojunior** » 01 Fev 2018 11:22

JoséQuintas escreveu:Talvez o ideal fosse juntar todas numa só, e centralizar os recursos que já foram criados.
Um começo pra isso
https://github.com/JoseQuintas/allgui
Só que isso não será possível se não for exclusivamente Harbour, o que pode gerar outro problema.

Isso causaria um problemão, pelo menos para mim: O que fazer com milhares de linha de código em sistemas que já estão rodando em centenas de clientes ?

por **sygecom** » 01 Fev 2018 12:00

JoséQuintas escreveu:Talvez o ideal fosse juntar todas numa só, e centralizar os recursos que já foram criados.

Um começo pra isso

https://github.com/JoseQuintas/allgui

Só que isso não será possível se não for exclusivamente Harbour, o que pode gerar outro problema.

Zé
Nesse caso temos a QTxHB, que já tem algumas Sintaxe da Hwgui e Minigui. Claro que nesse caso, teríamos que ver com o Marcos Gambeta a disponibilidade dele, ou ver se alguém pode entrar no projeto adicionando as sintaxe das outras LIB, isso resolveria também e, de cara já ganharíamos milhares de recursos que a QT já oferece.

por **MSDN** » 01 Fev 2018 12:07

O que Sygecom disse eu acho correto pq vai além do presente, no momento, temos com o que nos virar e fazer os sistemas, o problema é o futuro, que aliás, não está assim tão longe...
O Marcos, pelo seu histórico de pesquisa e desenvolvimento, realmente, seria uma pessoa fundamental nesse processo.

por **alaminojunior** » 01 Fev 2018 12:12

Nesse caso temos a QTxHB, que já tem algumas Sintaxe da Hwgui e Minigui

Outra coisa que vejo como fundamental, é manter a sintaxe atual da HwGUI. Isso vai manter vivo e aquecido tudo que já existe rodando.

por **JoséQuintas** » 01 Fev 2018 12:17

O que não tem no XHarbour... acrescentar.
Fonte pra Windows não ter que estar na LIB gráfica, e sim na HBWIN.
XHarbour também tem HBWIN, então é só colocar fonte no lugar certo.
Não tem que ficar consertando o Xharbour em todas as LIBs, basta colocar uma vez só no lugar certo.
Se não for pra padronizar, será pra bagunçar, que é o que sempre acontece.
A proposta é fazer organizado ou bagunçado?
Se for organizado, é cada coisa no seu lugar.

Mover uma janela/controle no Windows, algo como:
MoveWindow( hWnd, top, left, bottom, right )

Quantas rotinas iguais a essa são necessárias?
Uma só pra todas as LIBs, em C, pra ser usada no Harbour.
Não trocentas rotinas em C pra fazer a mesma coisa.

Lógico... tem certos comandos que são executados diretamente pela janela/controle, e tem comandos que a janela "pai" é que precisa "avisar" o sub-controle/sub-jasnela. Mas não é por isso que vai multiplicar as rotinas.

Mexer em LIB não é coisa de uma semana, nem um mês, vai ser um ano ou mais.
Um ano de trabalho pra continuar tudo igual, sem padronização.... perda de tempo.
Um ano é muito tempo, tempo suficiente pra padronizar muita coisa.
Se API Windows é tudo igual, não precisa ficar em LIB gráfica, precisa ficar na LIB Windows - HBWIN.

Se tudo ficar na hbwin... pronto, acabaram-se as diferenças de fonte entre Harbour/XHarbour existentes nas LIBs.
Existe diferença entre Harbour/XHarbour? Sim, mas não precisa inventar mais diferenças do que já tem.

por **MSDN** » 01 Fev 2018 12:22

Falou bastante e disse tudo, se for pra fazer, que seja da forma certa !

por **JoséQuintas** » 01 Fev 2018 12:25

Outra coisa que vejo como fundamental, é manter a sintaxe atual da HwGUI

Isso é outra coisa que não entenderam.
Manter sintaxe pode significar manter cagadas.
A sintaxe das LIBs é uma merd., estragam Harbour e XHarbour.

OOP é quase a mesma coisa, e mais flexível.

Lógico... OOP vai bem com uma IDE decente, e quando digo IDE não é amostra grátis de desenhar tela, é um ambiente de desenvolvimento mesmo, desenhar tela é o menor dos problemas.

Sem IDE... validações de fonte são problema.
Talvez essa seja a única vantagem da sintaxe das LIBs, definidas por .CH ou #translate, ou algo assim.

por **JoséQuintas** » 01 Fev 2018 12:29

Se não entenderam esta última parte:

DEFINE WINDOW x
   HEIGHT 10
   WIDTH 20
   TOP  10
   LEFT 20
END WINDOW

WITH x := Window():New()
   :Height := 10
   :Width := 20
   :Top := 10
   :Left := 20
END WITH

No segundo caso, de OOP, na compilação não vai avisar se escrever HEIGTH ao invés de HEIGHT.
Seria pra isso a IDE, uma checagem que a compilação normal não faz, ou até ajuda na digitação do fonte pra evitar erros.

por **alaminojunior** » 01 Fev 2018 12:46

Para quem ainda vai iniciar no uso da super biblioteca, ou está iniciando ainda com poucos trabalhos já feitos, maravilha ! Assino embaixo !
Agora ... e o que já existe ?

por **MSDN** » 01 Fev 2018 13:00

Alamino, eu não uso HwGUI, mas conheço sua sintaxe, e entendo bem o que vc falou, porém, como eu já mencionei mais acima, a palavra aqui seria " Futuro ", e para que isso ocorra, deve existir certas rupturas, bem como disse o Quintas.
Deve-se levar em conta que uma IDE que realmente funcione, e uma sintaxe voltada para OOP, é fundamental.
Imagine o seguinte, vc faz um sistema e procura mão de obra para empregar em sua empresa, porém ninguém conhece HwGUI e Harbour, mas se existir uma sintaxe OOP semelhante ao que já se usa em .NET, Java, fica muito mais fácil.

por **alaminojunior** » 01 Fev 2018 13:17

a palavra aqui seria " Futuro "

Precisamos considerar que existe um presente !

por **MSDN** » 01 Fev 2018 13:58

Concordo que existe o presente, porém, nessas horas, quando cogita-se algo novo, e que supra tanto o presente como o futuro, é preciso ir além, caso contrário, o Dbase III Plus ainda estava bom ! Vamos pegar como exemplo a seção Clipper aqui do Fórum, estamos em 2018, Harbour existe desde 1999 ( 19 anos ), o que pode prender um programador a uma linguagem que gera executáveis 16 bits ? Sendo que, em menos de 1 dia, pode-se sair do Clipper para o Harbour !! Imagina um programador Clipper "sofrendo" com um sistema que não imprime em qualquer impressora, que não acessa banco de dados relacional, etc, perdendo clientes, sendo que no fundo, o problema não é de ordem técnica, o problema é ele !
É um ponto polêmico, fico apto a levar pedrada, mas na essência é isso, ou a gente sai da zona de conforto e vai pra frente, ou deixa como está !

por **pauloa1** » 01 Fev 2018 14:22

Ao meu ver no momento precisamos algo sobre o presente.
Isso não quer dizer que se fizermos um grupo pago para melhorias na hwgui, estaremos presos na mesma.
Isso seria para um primeiro momento, depois dentro desse mesmo projeto, já podemos começar a discutir algo como os colegas colocaram.

Paulo

por **JoséQuintas** » 01 Fev 2018 15:52

Talvez fique até mais simples.

#xcommand INIT WINDOW <oWnd>                ;
             [ MAIN ]                       ;
             [<lMdi: MDI>]                  ;
             [ APPNAME <appname> ]          ;
             [ TITLE <cTitle> ]             ;
             [ AT <x>, <y> ]                ;
             [ SIZE <width>, <height> ]     ;
             [ ICON <ico> ]                 ;
             [ COLOR <clr> ]                ;
             [ BACKGROUND BITMAP <oBmp> [ STRETCH <nStretch>] ] ;
             [ STYLE <nStyle> ]             ;
             [ FONT <oFont> ]               ;
             [ MENU <cMenu> ]               ;
             [ MENUPOS <nPos> ]             ;
             [ ON MENU <bMdiMenu> ]         ;
             [ ON INIT <bInit> ]            ;
             [ ON SIZE <bSize> ]            ;
             [ ON PAINT <bPaint> ]          ;
             [ ON GETFOCUS <bGfocus> ]      ;
             [ ON LOSTFOCUS <bLfocus> ]     ;
             [[ON OTHER MESSAGES <bOther>][ON OTHERMESSAGES <bOther>]] ;
             [ ON REFRESH <bRefresh> ]      ;
             [ ON CLOSEQUERY <bCloseQuery> ];
             [ ON EXIT <bExit> ]            ;
             [ HELP <cHelp> ]               ;
             [ HELPID <nHelpId> ]           ;
          => ;
          <oWnd> := HMainWindow():New( Iif(<.lMdi.>,WND_MDI,WND_MAIN), ;
             <ico>,<clr>,<nStyle>,<x>,<y>,<width>,<height>,<cTitle>, ;
             <cMenu>,<nPos>,<oFont>,<bInit>,<bExit>,<bSize>,<bPaint>,;
             <bGfocus>,<bLfocus>,<bOther>,<appname>,<oBmp>,<cHelp>,<nHelpId>,;
             <bCloseQuery>,<bRefresh>,<bMdiMenu>,<nStretch>)

Em oop, vão continuar sendo várias linhas de resultado, mas usando OOP ao invés de muuuitos parâmetros que impedem mexidas adicionais.
Apenas a prioridade deixararia de ser compatibilidade, mesmo que a princípio tudo indique que vai continuar existindo.

Em HMGExtended isso é mais perceptível... só não pode usar codeblock em grids porque o arquivo .CH foi definido de modo a não permitir isso.

por **asimoes** » 01 Fev 2018 20:23

Considerando isso Quintas, teria uma sintaxe obrigatória pra funcionar e sintaxe adicional (opcional), uma super classe atendendo todas as necessidades.

Quem está online