starseeker (Jun 23 2020 at 00:03): starseeker (Jun 23 2020 at 00:03):Hey @Sean , what was the name of that interactive drawing language you were showing me a while back? Some sort of 2D graphics description language, but I'm blanking on what it was called.
Sean (Jun 23 2020 at 00:04):Processing
Erik (Jun 23 2020 at 00:34):logo?
starseeker (Jun 23 2020 at 13:55): Sean (Jun 25 2020 at 12:52):It's worth pointing out that mathematica/octave and matlab have a roughly similar facility, not as well designed but as powerful if not more powerful.
starseeker (Jun 25 2020 at 13:04):I was just kicking idle ideas around for what a generic libdm/fb 2D drawing API should look like - right now we've got a bunch of functions like drawLine3D, drawPoint2D, drawVList, etc. Was wondering if using a processing-ish set of commands as the wrapper API for the 2D drawing portions of the display manager's API might be cleaner, but unfortunately that would be a pretty major (and disruptive) migration to attempt.
Sean (Jun 25 2020 at 13:04):would definitely be cleaner
Sean (Jun 25 2020 at 13:07):the way to go would probably be to just try and implement processing/octave/matlab as a libged command with subcommands that are or are like the processing API, then make lib changes accordingly to support each new subcommand.
starseeker (Jun 25 2020 at 13:11):/me nods - makes sense. The thing to do first then would probably be to consolidate as many of the libdm backends as possible, to make it easier to rework the backend implementations to support such an API.
Sean (Jun 25 2020 at 13:12):that could all be for naught though
starseeker (Jun 25 2020 at 13:13):how so?
Sean (Jun 25 2020 at 13:14):it's possible there's already enough flexibility to do everything processing allows, or that only a couple trivial changes are needed to support feature xxx
Sean (Jun 25 2020 at 13:14):don't get me wrong, I like an architecture refactoring cleanup
Sean (Jun 25 2020 at 13:14):just may or may not really be needed to support something like processing
starseeker (Jun 25 2020 at 13:15):Ah, gotcha. Staring at things like the ogl_draw* function list has been making me wince
starseeker (Jun 25 2020 at 13:15):conflating issues
starseeker (Jun 25 2020 at 13:17):It may well be that this level of verbosity is needed - I've not put the time in to be sure one way or the other... Figured Processing would be a decent framework to use to decide "does it really need to look like this?"
Sean (Jun 25 2020 at 13:18):just thinking through the processing api, there's not much we couldn't do today -- maybe ten%?
it'd definitely help as a model if reflected down through. I just suspect it'd amount to mostly a renaming-of-functions exercise, not actually adding/changing lib functionality.
starseeker (Jun 25 2020 at 13:19):that'd actually be a lot better - much more potentially practical. Especially since we probably don't need all of Processing for our needs anyway, at least as a first cut
Last updated: Oct 09 2024 at 00:44 UTC