 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 05/10/2018 à 20:43, clipka a écrit :
> Am 02.10.2018 um 20:27 schrieb jr:
>
>> frankly, I'm not convinced it's worth the dependency. previous versions had a
>> "proper" X window[*], and I do not understand how abandoning that made
>> "maintainability" easier. all I see is a (big) library aimed at games
>> developers, none of its provisions used, except for the creation of a single
>> window. </rant>
>>
>>
>> [*] why can that (Xlib) code not simply be ported?
>
> I'm not an expert on this - neither do I have experience in working with
> Xlib or SDL, nor do I know the historic background - but I assume it's
> as simple as this:
>
> (1) The code interfacing with Xlib was difficult to maintain.
>
> (2) Something cropped up that made maintenance virtually inevitable.
>
>
> My bet for (2) is on the transition from the single-threaded POV-Ray
> v3.6 to the multi-threaded POV-Ray v3.7, either directly or via the
> architectural changes required.
Looking at history, the SDL was introduced in povray to replace both X11
and SVGA console driver. (that svga was a pain to use, but it was made
to have a povray similar to the MS-DOS version).
it occurred between 3.5 and 3.6 (between 2003 & 2004)
>
> An alternative candidate reason would be a newly discovered severe bug
> or limitation; or an existing moderately severe bug or limitation that
> had been deemed impossible to fix with Xlib, but had been accepted due
> to a lack of alternative before the advent of SDL.
>
I guess it was just simpler to delegate the whole issue of X11 & SVGA to
a single code and library.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 08/10/2018 à 13:23, Le Forgeron a écrit :
>
> Looking at history, the SDL was introduced in povray to replace both X11
> and SVGA console driver. (that svga was a pain to use, but it was made
> to have a povray similar to the MS-DOS version).
>
> it occurred between 3.5 and 3.6 (between 2003 & 2004)
Nah, it occured in 3.7, 3.6 is still using svga & X11.
Always check before posting...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Le Forgeron <jgr### [at] free fr> wrote:
> Le 05/10/2018 à 20:43, clipka a écrit :
> > Am 02.10.2018 um 20:27 schrieb jr:
> >
> >> frankly, I'm not convinced it's worth the dependency. previous versions had a
> >> "proper" X window[*], and I do not understand how abandoning that made
> >> "maintainability" easier. all I see is a (big) library aimed at games
> >> developers, none of its provisions used, except for the creation of a single
> >> window. </rant>
> >> [*] why can that (Xlib) code not simply be ported?
> > I'm not an expert on this - neither do I have experience in working with
> > Xlib or SDL, nor do I know the historic background - but I assume it's
> > as simple as this:
> >
> > (1) The code interfacing with Xlib was difficult to maintain.
> >
> > (2) Something cropped up that made maintenance virtually inevitable.
> >
> >
> > My bet for (2) is on the transition from the single-threaded POV-Ray
> > v3.6 to the multi-threaded POV-Ray v3.7, either directly or via the
> > architectural changes required.
>
> Looking at history, the SDL was introduced in povray to replace both X11
> and SVGA console driver. (that svga was a pain to use, but it was made
> to have a povray similar to the MS-DOS version).
>
> it occurred between 3.5 and 3.6 (between 2003 & 2004)
>
> >
> > An alternative candidate reason would be a newly discovered severe bug
> > or limitation; or an existing moderately severe bug or limitation that
> > had been deemed impossible to fix with Xlib, but had been accepted due
> > to a lack of alternative before the advent of SDL.
> >
>
> I guess it was just simpler to delegate the whole issue of X11 & SVGA to
> a single code and library.
given the threads issue you mentioned, maybe a different library altogether? I
think Tk would "fit the bill" in many respects.
regards. jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 08.10.2018 um 21:33 schrieb jr:
>> I guess it was just simpler to delegate the whole issue of X11 & SVGA to
>> a single code and library.
>
> given the threads issue you mentioned, maybe a different library altogether? I
> think Tk would "fit the bill" in many respects.
Don't come anywhere /near/ the POV-Ray code with C++/Tk! That thing is
an abomination, a Frankensteinian monstrosity.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymousorg> wrote:
> Am 08.10.2018 um 21:33 schrieb jr:
> >> I guess it was just simpler to delegate the whole issue of X11 & SVGA to
> >> a single code and library.
> > given the threads issue you mentioned, maybe a different library altogether? > >
I think Tk would "fit the bill" i
n many respects.
>
> Don't come anywhere /near/ the POV-Ray code with C++/Tk! That thing is
> an abomination, a Frankensteinian monstrosity.
lol. (that sounds almost like .. allergic)
well I can't "speak" C++ so really cannot comment. as component in a C program
though, Tcl (and Tk) are pretty straightforward wrt using. there are of course
"problems", like (n)curses and Tcl wrangling over who controls the std* streams,
otoh, Tk (with Tcl, Perl, whatever) runs on all platforms. (I'd love to know
though what makes it "monsterous").
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/08/2018 04:00 PM, clipka wrote:
>
> Don't come anywhere /near/ the POV-Ray code with C++/Tk! That thing is
> an abomination, a Frankensteinian monstrosity.
>
Oh it can't be any worse than X11. (I can't believe such a thing could
come out of MIT. I thought those were smart people? 'X' reeks of
designed by a committee of budgies.)
The Qt thing is pretty slick. Maybe I should make an edition that is
straight command line plus preview window.
--
dik
Rendered 1024 of 921600 pixels (0%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
dick balaska <dic### [at] buckosoftcom> wrote:
> On 10/08/2018 04:00 PM, clipka wrote:
>
> >
> > Don't come anywhere /near/ the POV-Ray code with C++/Tk! That thing is
> > an abomination, a Frankensteinian monstrosity.
> >
>
> Oh it can't be any worse than X11. (I can't believe such a thing could
> come out of MIT. I thought those were smart people? 'X' reeks of
> designed by a committee of budgies.)
fwiw, from a user perspective X11 is hard to beat. I /like/ being able to run a
program on machine A and getting the i/o forwarded to machine B, without needing
VNC or RDP or whatnot.
> The Qt thing is pretty slick. Maybe I should make an edition that is
> straight command line plus preview window.
with "-into" option a la Xterm?
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 06/10/2018 à 19:39, Le_Forgeron a écrit :
> Le 06/10/2018 à 12:04, William F Pokorny a écrit :
>
>> Glad to hear you are making progress.
>>
>
> And at the current state, I learn that libsdl (1.2 and 2) is not thread
> friendly, it wants (nah, requires) that the thread that make the display
> and pull event to be the MAIN thread (and not another child, even if
> alone to make the calls)...
>
> But it's working with libsdl2. As a kludge so far.
>
Now integrating... and the more I know libsdl & libsdl2, the more I hate
them.
I was hoping to have both kind of display available, when both are
installed, and selecting the one which is present when one only is
there, even allowing the user to select explicitly amongst SDL, SDL2, or
text.
They made incompatible API, on purpose they said... so it might have
been possible.
But :
* their include files define the same macro and define, but do not use
the same protection mechanism (that part, I can handle more or less, not
elegant, but doable)
* they kept some identical function interface, including SDL_Init() !!
which means the first linked library initialize its internal structure
and blocks the initialization for the second library, and without
initialized structure, other calls crash.
So back to the blue-print, to make a choice between SDL2 and SDL when
both are present... and maybe restoring the raw X11 port, updated for
the new rendering mode of block, that one could be safe to live in
parallel with SDL(1/2). [should I nickname SDL Ranma ? maybe, as you can
only have one at the same time, but at least Ranma 1/2 is a funny anime,
and I like Ranma, not SDL)
Given the added value of SDL2 vs SDL (the title of the window is set and
updated on pause with SDL2), the hierarchy seems obvious when both are
available.
(yet, have to allow --without-.. to allow user to force the choice)
See you next week.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 08.10.2018 um 22:16 schrieb jr:
> hi,
>
> clipka <ano### [at] anonymousorg> wrote:
>> Am 08.10.2018 um 21:33 schrieb jr:
>>>> I guess it was just simpler to delegate the whole issue of X11 & SVGA to
>>>> a single code and library.
>>> given the threads issue you mentioned, maybe a different library altogether? > >
I think Tk would "fit the bill" i
> n many respects.
>>
>> Don't come anywhere /near/ the POV-Ray code with C++/Tk! That thing is
>> an abomination, a Frankensteinian monstrosity.
>
> lol. (that sounds almost like .. allergic)
>
> well I can't "speak" C++ so really cannot comment. as component in a C program
> though, Tcl (and Tk) are pretty straightforward wrt using. there are of course
> "problems", like (n)curses and Tcl wrangling over who controls the std* streams,
> otoh, Tk (with Tcl, Perl, whatever) runs on all platforms. (I'd love to know
> though what makes it "monsterous").
The C++/Tk authors boast that their library pretty much preserves the
syntax familiar from Tcl/Tk.
The Tcl syntax is /very/ different from common C/C++, and to achieve
this feat they used some features of the C++ language in manners that
would make every sane C++ programmer's skin crawl.
C++/Tk is, in every sense, a joke takem too far.
I didn't even know C bindings for Tk existed; maybe they are more
faithful to the target language.
I'm not sure how Tcl as a component in a C program would look like.
After all, last time I checked, Tcl is a language, not a library.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
clipka <ano### [at] anonymousorg> wrote:
> Am 08.10.2018 um 22:16 schrieb jr:
> >> I think Tk would "fit the bill" in many respects.
> >> Don't come anywhere /near/ the POV-Ray code with C++/Tk! ...
> > I'd love to know though what makes it "monsterous").
> The C++/Tk authors boast that their library pretty much preserves the
> syntax familiar from Tcl/Tk.
this is the first time I have seen "C++/Tk" juxtaposed.
afaik, the only thing (Tcl/)Tk and C++ have in common is the (approximate) year
of when development began; Tcl turned 30 last year.
> The Tcl syntax is /very/ different from common C/C++, and to achieve
> this feat they used some features of the C++ language in manners that
> would make every sane C++ programmer's skin crawl.
and it does not make sense (to me, at any rate). the whole "idea" is either of
two deployment scenarios:
a) you have some kind of interpreter/shell and provide applications as scripts,
perhaps supported by custom shared libs.
b) you integrate one or more interpreters in your own, usually C, code, and
provide part(s) of the application functionality as scripts (built-ins or user
supplied, whatever).
there's literally no point[*] in the exercise you described.
[*] again, just me.
> C++/Tk is, in every sense, a joke takem too far.
it does sound a little .. perverted.
> I didn't even know C bindings for Tk existed; maybe they are more
> faithful to the target language.
it's how it (Tcl) started. as a C library to provide a "tool control language",
to drive other command-line apps. Tk was (so I read) an effort to build on
Apple's HyperCard concept(s) but constrained by need to be modular.
the introduction to the first edition of the "Tcl and the Tk Toolkit" book by
*the man* John Ousterhout (Addison-Wesley Publ.) makes excellent reading.
alternatively, reading
https://en.wikipedia.org/wiki/Tcl#Interfacing_with_other_languages
followed by
https://en.wikipedia.org/wiki/Tcl#Syntax_and_fundamental_semantics
gives an ok outline.
> I'm not sure how Tcl as a component in a C program would look like.
> After all, last time I checked, Tcl is a language, not a library.
a really sharp language lawyer might argue it isn't even a language - as such,
more a set of (12) rules for parsing + substituting strings (EIAS =="everything
is a string"). Tcl has no reserved "keywords", any and all commands can be
renamed (or deleted).
(as an analogy, think of each Tcl command as a separate "program", each taking
one or more argument "words" and returning one result (perhaps empty))
as component of a C (or other compiled) application, it provides access to
scripting via one or more interpreters you create; and has "goodies"
(conveniences?), like easy hash tables etc.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
