Re: hbui - GUI
Itamar Lins
Em sexta-feira, 28 de fevereiro de 2020 08:49:26 UTC-3, Rafał Jopek escreveu:
Hi,libui is a great development project, all basic controls are done in this tables.Stargazers: 9 237 libuiStargazers: 181 HarbourI can't understand this phenomenon.All programming languages have a GUI with open source code, only Harbour remains lonely in project 3.2 and 3.4 I do not see.Well, probably nobody is interested in GUI.I made a website for hbui, using Jekyll which is hosted free on HitHub.Anyone have any comments on my project, or someone wants to contribute to this project?We know that there is much to do here.- Rafał
Eric Lendvai
"libui is currently mid-alpha software. Much of what is currently present runs stabily enough for the examples and perhaps some small programs to work, but the stability is still a work-in-progress, much of what is already there is not feature-complete, some of it will be buggy on certain platforms, and there's a lot of stuff missing. In short, here's a list of features that I would like to add to libui, but that aren't in yet"
There are also 66 pending pull requests and no code changes in 2 months.
But overall your Habour wrapper around it is promising!
Itamar Lins
José M. C. Quintas
Problems are:
- Users already using GUI, do not want test another GUI, may be
wants continue with same GUI, or go to web
- Users using console, there are most of them who do not knows
about OOP programming, others wait for a magic GUI without rewrite
code, others do not need GUI, others have big projects
And in the other side, a GUI need users, to explore all features
and ask for new features.
May be a good result will occurs only when the main part of libraries remains inside Harbour, as part of core or as a contrib.
Using Windows as example, many of Windows API is inside hbwin, and libraries do not use it.
If Windows API cannot be the same to libraries, what about the other things?
Remember that Harbour 3.4 is configured to generate binaries, setup is part of github download.
If GUI libraries comes to github and uses this feature, all GUI libraries would becomes updated and with binaries allways ready to use.
But no standard for single things, then no standard visible to
all on fucture.
May be this "single" feature could be the begin to group all
libraries, and move main GUI library control inside Harbour.
After this, all libraries and all users could add new controls to any library.
Any big change starts with small changes.
And may be that, to make this possible, need changes XHarbour too, because several libraries have source code to Harbour and XHarbour.
A Library cannot use hbwin from Harbour, if XHarbour do not have same feature on its hbwin, then libraries create new routines to work for both compilers.
And this forces libraries allways depends of a master C to make
changes on libraries.
If masters of C works on core, other users could works on
libraries or on controls.
We have few C programmers, but too may PRG programmers.
I see about this when I create some extra controls to GTWVG: I do not have C knowledge but PRG knowledge.
When Viktor move Windows API calls from GTWVG and GWVW to a standard hbwin call, from PRG, I could made changes.
Before this: nControlSize /2, do not return nControlSize / 2, because nContriSize was not a valid Harbour number, but a C number.
May be is needed go back, before go ahead.
José M. C. Quintas
José Quintas
Em sexta-feira, 28 de fevereiro de 2020 10:48:12 UTC-3, José Quintas escreveu:
May be is needed go back, before go ahead.