La Classe Window in gb.qt4 va in contrasto con gb.ncurses

[vuott]

Vorrei riportare questa disussione apparsa nella M.L.I.:


« Recently a friend of mine reported an issue that I'm not sure how to explain correctly.
He is making a terminal program that needs to print stuff on a real printer, so it needs the gb.qt4 component to get access to the Printer object. But also he needs to use gb.ncurses to do some neat presentation in a terminal in a kind of interactive mode. Problem arises when the *Window* class in gb.ncurses collides with the same class name in gb.qt4 (needed to gain access to printer functions) It seems that window class in gb.qt4 surpasses the one in gb.ncurses.
So, is it a known problem? Does anyone realized this "incompatibility" when using both components at the same time?
Is there a way to use the printer without using gb.qt4?

Jesus »


« I never thought of using a graphical component together with gb.ncurses. I
never intended that :-) The thing is, the only way to make gb.ncurses'
TUI-graphical classes compatible with X-graphical classes is to insert dummy
methods and properties (e.g. Opacity, Picture) that do nothing and at the
same time to remove ncurses-specific functions (e.g. Print, Cls) which makes
it twice ungood. Removing such methods calls for something like a Draw class
as a replacement interface which doesn't make much sense as only text can be
displayed (there would be more dummy functions for the Draw class).

What do you mean actually by "surpasses"? Is there an "incorrectly
overridden" error or does the gb.qt4 Window just override[0] the gb.ncurses
one? If the latter is the case, you can try to disable gb.ncurses and
Component.Load() it manually at startup?

I promise that future control classes and a future Window class (using the
CDK) are more built like their gb.qt4 models but for now think of gb.ncurses
as a component that conflicts with other graphical components. I don't think
compatibility can ever be achieved, though.

Anyway, good to know that someone can do "neat presentation"s with
gb.ncurses :-)

Regards,
Tobi

|0| Here is what happens:
http://gambasdoc.org/help/doc/object-model?v3 »


« Yes. The point is, how it is supposed to do printing from within
gb.ncurses without using the Printer object (found only inside graphical
components)?

We then should need to do this through CUPS or something, doesn't it?

The fact is my friend is trying to print a kind of report based in his
own classes that uses Draw and Paint to actually draw a report in a
drawing area when using the full program version, and the file
representing the report itself is interpreted and printed from an
stripped out version of the program that only works in console mode
(interactive curses interface). The logic of printing is the same for
both programs, so qt4 is needed to do all the stuff. Sources here:
http://forge.gambas-es.org/projects/printreport/repository
and the parent project here:
http://forge.gambas-es.org/projects/reportdesigner/repository


Right, the latter is the case. It makes them incompatible with each other.

I think so, as well... but gb.ncurses programs would need to have a way
to print things. I remember old clipper database programs they were able
to print some kind of text based reports. It would be great if printing
could be based in actual drawing routines as qt4 does. But I understand
it probably never ever could be achieved.

Sorry, but finally he wasn't able to do something usable because of the
above reasons.

Honestly, I've never tried gb.ncurses. But I will do in the future, when
this is well documented ;-) My friend was complaining about complexity
and lack of documentation, but hey, we are very grateful of your work.
Really.

Best regards
--
Jesus Guardon »


« I don't think printing is something gb.ncurses should implement. In fact,
gb.ncurses has nothing to do with printing (on a printer) as ncurses does
not provide any function for it. It's just two (very) different things.
gb.qt4 just supports printers because QT, for some reason, provides an
interface for them.

If we support CUPS, then it should be in a gb.cups component so that
printing is not bound - again, for whatever reason (OK, there's printer
dialogs) - to a graphical toolkit. However, I'm not the person to do this
component and it should IMO not be located inside gb.ncurses.

Looking at the sources you pointed to, he should rather follow Benoit's
suggestion and make two different programs: one to provide the interface and
a hidden one called internally to print by means of QT. Not too pretty but
the easiest solution.

Yeah, I still hope for a kind of interface to the wiki that I can turn into
a scriptable program to eventually document easily (and happily). The
documentation should be deprecated in most parts since I wrote it...

However, I'm the living gb.ncurses documentation. You can contact me or the
entire list if you have questions. I'll do some examples, too.

Regards,
Tobi »


« A temporary solution will be to make a secondary project that manage the
printing.
Fabien Bodard »


« Priting from the command-line with cups (a five second google search!)

http://www.cups.org/documentation.php/options.html

Then you "just" have to generate your report in a format understable by
cups (PS, PDF, JPG mainly I think).

Regards,

--
Benoît Minisini »

[vuott]

...continua...


« Creating a report from a non-graphical method might prove difficult.

If you are planning on using something like report from an HTML template on
a PDF File you either need to make sure you can generate a PS or PDF file
or you can use wkhtmltopdf <https://code.google.com/p/wkhtmltopdf/> to
generate your PDF file then shell to lpr to send this to your printer.

Theoretically this could work but it will depend on what HTML features
wkhtmltopdf <https://code.google.com/p/wkhtmltopdf/> supports and how you
make your HTML template.

Dimitris Anogiatis »


« And you can use  gb.report and scripter.

Fabien Bodard »


« Well, it's clear that gb.ncurses isn't the way to go with this project.
I will tell him about your thoughts, so many thanks to all for taking
the time on this.

Regards
--
Jesus Guardon »