On 02/17/2015 11:30 PM, Jordan Justen wrote: > On 2015-02-10 12:09:05, Chad Versace wrote: >>> On Sun, Feb 08, 2015 at 07:50:15PM -0500, Frank Henigman wrote: >>>> I'd like to extend wflinfo so it can print platform-specific >>>> information and eventually be able to replace glxinfo, eglinfo and the >>>> like (I only know what's on linux). There would be a new flag to >>>> request the platform-specific output in addition to the existing >>>> output. For example on glx you'd see glx extensions, on egl you'd see >>>> egl extensions. >>>> I've started two different implementations and I'd like to know which >>>> is preferred before I go any farther. Or if there's a better idea >>>> than either of my approaches. I've dubbed the two approaches "native" >>>> and "core." >>>> >>>> native >>>> - all the work is done in wflinfo, no changes to waffle api >>>> - use waffle_display_get_native() to access platform-specific stuff >>>> - pro: changes limited to wflinfo, doesn't clutter up the rest of waffle >>>> - con: some duplicate code to open libraries and lookup symbols >>>> - https://github.com/fjhenigman/waffle/tree/ps_native >>>> >>>> core >>>> - add waffle_display_print_info() to waffle api >>>> - add print_info() method to each platform >>>> - pro: less code, no duplication >>>> - con (perhaps): some wflinfo functionality is now in core waffle >>>> - https://github.com/fjhenigman/waffle/tree/ps_core >>>> >>>> I'm leaning toward "core" because there is less code. We get to >>>> leverage the platform libraries and functions already stored in waffle >>>> platform structs. But if the consensus is it's cleaner to keep this >>>> stuff in wflinfo I'm ok with that too. >> >> I prefer "core" too. Not for the sake of less code, but because I like >> the idea of it being available as core API. > > This surprised me a bit. I wouldn't think of the waffle library > wanting to embed a bunch of strings to fulfill such an API.
Embedding string? I don't understand. Your proposal needs embedded strings too: the strings for the key values. If Waffle provides the display info in one big string or in a sequence of little strings, as you propose, the same key strings need to be embedded into the library. Am I missing something? > Anyway... how about this: > > char** > waffle_display_info_strings(struct waffle_display *self, bool verbose); > > The returned array of strings could have this property: > > First look for a key string pointer. If it is NULL, then you are done. > If you find non-NULL key string pointer then search for 0 or more > non-NULL value string pointers. When a NULL pointer is seen, go back > to looking for a key string pointer. > > I've attached an example program that sort of emulates wflinfo... > > This would allow the consumer to use comma separation and/or line > breaks as desired. For the sake of apps who want to dump the info to a log file or to the console and get on with their lives, I think the default output format should be a single, giant string. But, as we're discovering in this conversation, a single giant string might not be appropriate as a one-size-fits-all format. I believe we can have it both ways, though, by adding some optional parameters to the API. void* waffle_display_get_info(struct waffle_display *dpy, enum waffle_display_info_format format, uint32_t flags); Then we have the ability to define API like this: // Returns a single, string suitable for log output. The return value // must be cast to `char*`. One valid flag is currently defined for this // format, WAFFLE_DISPLAY_INFO_VERBOSE_BIT. waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_SIMPLE, 0) // Returns Jordan array of strings. The return value must be cast to `char**`. // One valid flag is currently defined for this format, // WAFFLE_DISPLAY_INFO_VERBOSE_BIT. waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JORDAN, 0); // Returns a JSON string. The return valud must be cast to `char*`. Two // flags are currently defined for this format: WAFFLE_DISPLAY_INFO_VERBOSE_BIT // and WAFFLE_DISPLAY_INFO_INDENT_BIT. waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JSON, 0); Of course, the "simple" and "jordan" formats will be the first ones implemented. People can implement other formats in the future. (The JSON format, I'm just using that as a hypothetical example.) Do you think this is a good compromise between usability and extensibility? Does my proposal lack some important knob you think is needed? Or is my proposal just overall a bad idea?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ waffle mailing list waffle@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/waffle