<InPhase>
I can post later, but a viable color syntax would be something like {color.red}, since color is a built-in, so we can special-purpose reuse this and know it won't be clobbered by user variables.
<InPhase>
Then we can fill it with html or ansi color codes depending on gui vs command line.
<InPhase>
Then we can add yet another command line flag for the inevitable person who wants the console output to be html too. ;)
<InPhase>
Or output format output.html
<InPhase>
.html might make more sense if that's desired, so <p>...</p> can be used.
califax has quit [Remote host closed the connection]
califax has joined #openscad
mhroncok has quit [Quit: Leaving.]
<teepee>
it might be useful to look at other tools, like git has something for that in it's formatting output
<InPhase>
We'd need something that can either call our own lookup handler, or we'd have to roll our own formatting parser.
<InPhase>
It's not too tricky to do for basic features.
<teepee>
which is why I'd prefer using fmt / std:.format
<InPhase>
But does that have anything that takes a lambda?
<teepee>
it's a bit annoying that we can't just go standard as that's only in c++20 but I suppose it's still better than inventing something new
<teepee>
it's meant to be extensible, I've not looked at the details, and it probably means wading through lots of templates, but it's not like printf where the feature set is fixed
<InPhase>
I also have 100 lines of code that provide 100% support of ansi terminal features that work in modern terminals with in a properly structured C++ class. There's not much to the ansi part.
<teepee>
the interesting part is the integration with the GUI
<teepee>
at least it would be a useful feature to allow both to be handled with the same format string
<InPhase>
Qt will accept html for the color. It just needs to use the right output form.
<InPhase>
Hence my abstracted {color.red} idea.
<teepee>
yes, but it never really worked with all the extra feature of html like collsapsing whitespace and such
<InPhase>
Ah, that.
<teepee>
and all the cases of missing closing tags that can happen
<InPhase>
Well we wouldn't want to allow user html.
<teepee>
I assume we may want to have all attributes reset at the end of a single print() call
<InPhase>
But yeah, collapsing whitespace would be a challenge. :)
<InPhase>
Yes, I think so.
<InPhase>
Either that or we would need a smart console tracking its color state.
<teepee>
the problem with html is that we have no control once we give users the means to insert tags
<peepsalot>
the Qt console output was reworked to avoid HTML, and sets colors for Qt's rich text format directly, for performance reasons
<InPhase>
peepsalot: Honestly I've been strongly contemplating abandoning Qt for my other projects. I fear Qt6 might be hopelessly broken for the normal reliability requirements I have, as they've banned top-level exception handling for events.
<InPhase>
peepsalot: It will be an ordeal to switch my habits and source code infrastructure to a new system, but their philosophy is growing too broken to keep dealing with. I don't like Qt's philosophy of trying to keep users thinking it's not free in the first place, but I stuck with it only because it appeared to be the best thing out there. But if they're going to go and break reliability guarantees, then
<InPhase>
it's really not anymore.
<InPhase>
I was looking at Dear ImGUI the other day, and I'm intrigued by this approach. It looks like on the whole it is much lower overhead and results in smaller UI code by completely avoiding a UI object model layer passing data back and forth.
<peepsalot>
ah, yeah. imgui is interesting. magnum has some integration for that too btw ;)
<InPhase>
And on top of that, you get video rate updating of UI features.
<teepee>
yeah, I feel we are now in a situation that's very unfortunate
<teepee>
can imgui do accessibility stuff?
<InPhase>
Plus, Dear ImGUI seems like it seamlessly moves the interface into and out of web browsers.
<InPhase>
teepee: Well, like?
<InPhase>
teepee: Text to speech things?
<peepsalot>
ditching qscintilla would probably be the most difficult aspect
<teepee>
screen readers, ...
<InPhase>
teepee: I'm not sure how that would work.
<teepee>
well, there's a opengl version of scintilla in bonzomatic :)
<InPhase>
Yeah, it looks like people have put scintilla into imgui.
<InPhase>
Any change of that scale would be an ordeal. But I've just been getting concerned enough to start evaluating this for my other work.
<InPhase>
And I kind of like the notion of accelerated interfaces.
ali1234 has joined #openscad
<InPhase>
The advocates all report that the overhead is lower than something like Qt for most things, although there are some cases where Qt will be lower overhead.
<InPhase>
Things like scrolling should be much smoother.
<teepee>
at least I'm not so much concerned regarding the "non-free" part, I believe there's a good chance that continues to be a solved topic
<InPhase>
teepee: Well that's been a 30 year ordeal.
<teepee>
what is? converting OpenSCAD? yeah, probably
<InPhase>
lol
<teepee>
but there's some legal stuff in place to secure at least the open source state
<InPhase>
Yeah, a fork is always possible, but there isn't really community interest in it at present. The Qt Company is doing the heavy development on this library.
<InPhase>
CopperSpice already tried a fork back at 4.8, but it never picked up any interest.
<teepee>
no, not fork, there's a foundation with board members 50% from KDE
<InPhase>
Yeah. My main concern is how often I have to explain to people that Qt is actually open source and free, because their website misleads on this intentionally to sell extra licenses.
<InPhase>
They're required to continue providing it, but they are allowed to strongly mislead about it.
<teepee>
yeah, the official site and also their communication is certainly going into a not so nice direction, it feels like only dragging the desktop stuff around and caring only about mobile
<InPhase>
Right, that too. Their whole development agenda moves away from my interests and goals.
<teepee>
so I agree it's something to look at for new projects, but the concern for existing projects is likely less than it seems
<teepee>
at least mid term, lets say 5 years or so
<InPhase>
Well, I'm worried about what happens to my other projects once Qt5 becomes too aged to keep using.
<InPhase>
5.14 already breaks exception handling.
<InPhase>
I think that was the threshold version. Somewhere around there.
<InPhase>
In Qt6 it's to be purely broken.
ur5us has joined #openscad
<InPhase>
OpenSCADApp.cc line 52, for example, stops working in non-gui threads at 5.14, and will not compile for Qt6.
<InPhase>
Which is a massive problem.
<InPhase>
For OpenSCAD I don't think these exceptions happen very often, but I have a lot of code that relies heavily on this formerly standard approach as part of the infrastructure.
<InPhase>
Because, you know, programs should not crash...
<InPhase>
"However, be advised that you need to ensure ALL threads stop delivering events
<InPhase>
before your application object begins destruction. That includes threads you
<InPhase>
did not directly start, but were started on your behalf inside other libraries
<InPhase>
(and anywhere I didn't catch in Qt). If you can't guarantee that, stop
<InPhase>
overriding notify() -- there's no other possible solution.
<InPhase>
Whoops, bad paste.
<InPhase>
And, "This is not a new requirement. It's been there since Qt 3.0, but no one noticed until now."
<InPhase>
In fact, this was known long ago. But apparently the Qt devs rediscovered it and were shocked.
<InPhase>
So, they broke Qt6 exception handling to avoid the need to shut down threads.
<InPhase>
Maybe I misremembered the 5.14 part. I don't see anything about that there, but I thought there was some related change at this version.
<InPhase>
I figure there are a few years left of dragging feet on Qt5 before I need to find a solution, but it's worth starting to plan.
Guest8119 has joined #openscad
Guest8119 has quit [Client Quit]
<teepee>
yeah, that makes sense, but there's not an amazing list of options to select from
amahl has quit [Remote host closed the connection]
<InPhase>
teepee: Yeah. I did a survey of options the other day, and it seems like wxWidgets, gtk, and Dear ImGUI are the primary production-ready feature complete high-support options.
<InPhase>
I don't think I want to go back to gtk. Been there, done that, left for a reason. I'm not familiar with wxWidgets but rumor has it that it's a little unpleasant to work with the API. The Dear ImGUI users appear to rave about it, hence my curiosity about this. It's just... very different from how I'm used to thinking about UI design.
<InPhase>
But it might be different in a way that is empowering. I do notice the wastefulness of shuttling data back and forth in gui components that mirror non-gui components.
<InPhase>
I think that contributes a lot to the pain of restructuring anything that interfaces with the gui.
<InPhase>
Allegedly this is greatly reduced with ImGUI.
Junxter has quit [Ping timeout: 268 seconds]
snaked has joined #openscad
<JakeSays>
openscad needs a struct type thing
<JakeSays>
InPhase: personally i think qt is a much better platform than any of the alternatives you mention
<JakeSays>
wxwidgets is *very* MFC'ish
<JakeSays>
also i'm not too thrilled with qt6.
<JakeSays>
but.. openscad needs a struct. lol
ur5us has quit [Ping timeout: 260 seconds]
<InPhase>
JakeSays: See the object literals proposals. The design is at least in progress of being thought out.
<JakeSays>
InPhase: oh cool!
<InPhase>
And some foundation code is in place already from recent work.