| *** edogawa has quit IRC | 00:04 | |
| *** rncbc has quit IRC | 00:45 | |
| *** damo22 has joined #lv2 | 01:09 | |
| damo22 | hi, where is the code for LV2 that specifies how the UIs are integrated | 01:10 |
|---|---|---|
| damo22 | eg, is there a function pointer for a window generator callback | 01:10 |
| damo22 | or how do the UIs get called | 01:11 |
| *** trebmuh has quit IRC | 01:45 | |
| *** Yruama_Lairba has quit IRC | 02:31 | |
| ColaEuphoria_ | damo22, are you talking about this? http://lv2plug.in/book/#_simple_oscilloscope | 02:47 |
| drobilla | http://lv2plug.in/ns/extensions/ui/ ... | 03:25 |
| drobilla | First link in particular | 03:25 |
| *** funfunctor has joined #lv2 | 03:26 | |
| funfunctor | hi | 03:26 |
| funfunctor | damo22: | 03:27 |
| damo22 | gday | 03:27 |
| funfunctor | && drobilla | 03:27 |
| damo22 | drobilla: i was wondering why LV2 has different UI designations like CocoaUI etc and GtkUI, why not have them abstracted away so you can have a plugin launch the window it prefers and callback into the host? | 03:29 |
| *** funfunctor1 has joined #lv2 | 03:30 | |
| *** funfunctor has quit IRC | 03:30 | |
| damo22 | as an example, me and funfunctor have ported GLFW to the DPF toolkit and removed the need for pugl altogether | 03:30 |
| damo22 | but we're missing one crucial piece of the puzzle for embedding windows | 03:30 |
| funfunctor1 | technically ported DPF to glfw | 03:32 |
| damo22 | yeah sorry thats what i meant | 03:32 |
| *** funfunctor1 is now known as funfunctor | 03:32 | |
| funfunctor | drobilla: the issue is that parentId gets passed in to the constructor (intptr_tr) and is considered a X11 specific handle. glfw has a decent abstraction, GLFWwindow * and so we would need to pass that in instead | 03:34 |
| funfunctor | I'm not familiar with the architecture of things. I usually work on mesa and stuff so I am just helping damo22 out | 03:35 |
| drobilla | "missing one crucial piece of the puzzle" | 03:36 |
| funfunctor | damo22: has drobilla already seen the repo? | 03:36 |
| drobilla | In removing that "need" you also removed functionality | 03:36 |
| drobilla | Being the main point of pugl | 03:36 |
| funfunctor | drobilla: well no, glfw can do what pugl does except far better | 03:37 |
| drobilla | Which is specifically designed to be suitable for plugins, and embeddable, and whatnot, unlike GLFW, which isn't | 03:37 |
| funfunctor | its just the API's don't match 1:1 perfectly obviously | 03:37 |
| funfunctor | I understand pugl and glfw perfectly well. glfw is definitely fine as a replacement, that is for sure. | 03:38 |
| drobilla | Then you shouldn't have a problem using the provided parent window. | 03:38 |
| funfunctor | our question is more to do with fixing things up without too much perturbation to the overall design of the high level components, not if it can be done. | 03:39 |
| funfunctor | well the parent window seems to be a X11 low level handle to me | 03:39 |
| funfunctor | so you have a high level component passing a low level handle ?down? | 03:39 |
| drobilla | Yes. On X11, anyway (obviously). What else could it be? | 03:39 |
| funfunctor | makes no sense | 03:39 |
| funfunctor | a high level opaque handle handle | 03:40 |
| drobilla | It is the only thing that makes sense. On X11, that is what a window is. | 03:40 |
| drobilla | You can't have a high levle opaque handle | 03:40 |
| funfunctor | and what about wayland | 03:40 |
| drobilla | That's API specific. | 03:40 |
| drobilla | On Wayland it would be something else. As it is on Windows | 03:40 |
| drobilla | and OSX | 03:40 |
| funfunctor | why should the plugin framework be API specific to the windowing system | 03:40 |
| funfunctor | isn't the point is for it to abstract away windowing system specifics | 03:41 |
| drobilla | Because it can't be anything else. | 03:41 |
| drobilla | What else could any toolkit use? | 03:41 |
| drobilla | The native window type is the only common thing any API can use. | 03:41 |
| funfunctor | I am not talking about the toolkit | 03:41 |
| drobilla | Abstracting that away is the job of said API | 03:41 |
| funfunctor | I am talking about what is passed into the toolkit from above it | 03:42 |
| drobilla | If GLFW can't then it's hardly "far better" for this purpose | 03:42 |
| drobilla | Yes, and you want it to be... "a high level opaque handle". To what? | 03:42 |
| drobilla | How does the UI use this opaque handle to do anything? | 03:42 |
| funfunctor | I think the question we have hasn't been conveyed properly because this isn't the discussion we require to progress. | 03:43 |
| drobilla | The API is designed so UIs can be embeddable | 03:44 |
| funfunctor | I can see that | 03:44 |
| drobilla | There is exactly one thing that can serve this purpose and be used by any graphics API, and that is the native window handle, whatever that might be on the given platform. | 03:44 |
| drobilla | Thus the UI gets passed that and must draw to it. | 03:44 |
| drobilla | If you can't do that because your API sucks, you can use show/hide interface instead and lose embeddability. | 03:45 |
| drobilla | and regress DPF in the process of your "upgrade" ;) | 03:45 |
| *** unclechu has quit IRC | 03:45 | |
| *** funfunctor1 has joined #lv2 | 03:46 | |
| funfunctor1 | sorry, is there a backlog? | 03:46 |
| damo22 | i'll paste it to you funfunctor | 03:47 |
| funfunctor1 | thx | 03:47 |
| drobilla | topic. | 03:47 |
| drobilla | I can't tell what you want. Clearly the host can not pass a GLFWwindow* | 03:47 |
| *** funfunctor has quit IRC | 03:49 | |
| *** funfunctor1 is now known as funfunctor | 03:49 | |
| drobilla | As far as I can tell GLFW just can't embed. | 03:49 |
| funfunctor | drobilla: it depends what you mean by embedded | 03:50 |
| drobilla | I imagine it probably has a shitload of static stuff all over the place too, though that's just an assumption based on the things GL people tend to do. | 03:50 |
| drobilla | Misguided port IMO | 03:50 |
| damo22 | drobilla: isnt it also true that on some platforms, you cant draw native GL onto the parent window that you desire? | 03:50 |
| funfunctor | drobilla: the GL btw is garbage also in that library. Its using fixed pipeline stuff that needs replacing. | 03:50 |
| funfunctor | If you are saying porting from pugl to glfw is misguide I would peg to differ | 03:51 |
| drobilla | damo22: Not really. Drawing is always to a window. That's what a window system is. | 03:51 |
| drobilla | funfunctor: Yet here you are ;) | 03:51 |
| funfunctor | drobilla: actually no, GL draws go to a GL context not to a window | 03:52 |
| drobilla | YKWIM. | 03:52 |
| funfunctor | drobilla: I am here to communicate with developers not to argue silly points about not taking the time to understand why something is being done and being told its misguided | 03:52 |
| * drobilla shrugs | 03:53 | |
| drobilla | The thing you ported to seems unable to accomplish the task | 03:53 |
| funfunctor | drobilla: I may guess what you mean by damo22 may not. | 03:53 |
| drobilla | I'm sorry if you're a fanboy of it, but that's the reality of the situation. The actual, user-visible regression reality. | 03:53 |
| damo22 | drobilla: wouldnt it be nice if suil was not necessary? | 03:54 |
| drobilla | Add proper native window parenting to GLFW if you like | 03:54 |
| funfunctor | drobilla: that is ridiculous, let me rephrase that for you "the thing you are developing right now seems not to be finished" | 03:54 |
| funfunctor | ah damo22 I am wasting my time.. | 03:55 |
| funfunctor | now I am a fanboy | 03:55 |
| damo22 | idk | 03:55 |
| funfunctor | from someone who can't write GL code to someone who writes GL drivers | 03:55 |
| funfunctor | right oh | 03:55 |
| funfunctor | see you | 03:55 |
| *** funfunctor has left #lv2 | 03:55 | |
| drobilla | You reap what you sow | 03:55 |
| ColaEuphoria_ | i'm a bit too drunk right now what just happened | 03:56 |
| drobilla | I'm sorry that the host can't pass magic pixie fairie dust handles that don't even make sense, I guess? | 03:58 |
| ColaEuphoria_ | ayyy gurl can i get an SDL_Window* handle from the host too :DD | 04:02 |
| damo22 | what type of handle does the host export currently? | 04:03 |
| damo22 | it seems to be display manager/platform specific? | 04:04 |
| ColaEuphoria_ | It depends on what the host supports | 04:04 |
| ColaEuphoria_ | If I'm writing a host, I'd rather just support simply X11 than to try and cater to everyone and add support for gtk/qt/glfw/sdl/etc | 04:05 |
| ColaEuphoria_ | likewise with Windows where hosts only support HWND or something | 04:05 |
| damo22 | X11 is broken | 04:05 |
| damo22 | wayland is coming | 04:05 |
| ColaEuphoria_ | (tm) | 04:06 |
| ColaEuphoria_ | the point is that there is less onus on the host if all they have to do is support the lowest level native window handle | 04:06 |
| ColaEuphoria_ | on windows i believe that is HWND | 04:06 |
| ColaEuphoria_ | linux as of now is X | 04:07 |
| damo22 | if the host is suil then you could have a callback you pass, and native embed using that callback becuase the GL draws dont go to a window they go to a GL context | 04:07 |
| damo22 | you could handle *any* native window handle inside suil based on the platform youre on | 04:09 |
| damo22 | GLFW is just an example of how to do this | 04:10 |
| drobilla | damo22: The Gtk/Qt parts, sure. Which is exactly why talking in native window handles is the way forward | 04:13 |
| ColaEuphoria_ | damo22, Are you asking why hosts don't just care about the renderer and find its own way to make a window for it? | 04:13 |
| drobilla | I don't understand what that's trying to say. "A callback you pass and native embed using that callback"? | 04:14 |
| drobilla | To embed is to embed in a window, in practice | 04:14 |
| drobilla | Let me put it this way | 04:14 |
| drobilla | Having a (in this case) X window to draw in is not some design decision | 04:14 |
| drobilla | It's reality | 04:14 |
| *** unclechu has joined #lv2 | 04:15 | |
| drobilla | The choice is either to pass that native handle to the UI, or try to move some abstraction up into the host and pass <some other thing> | 04:15 |
| drobilla | The former means you can draw with anything that supports, well, drawing on the platform | 04:15 |
| drobilla | The latter means... well, I'm not sure what it means. Either it can give you that same native window handle, or it does nothing useful at all | 04:16 |
| *** hybrid has quit IRC | 04:17 | |
| drobilla | If you have a graphics API that literally can not embed, period, there is no change to the LV2 UI interface that can change that | 04:17 |
| damo22 | drobilla: but if the LV2 api had a way for the plugin to set a callback for dispatching GL rendering commands instead of being passed a native window handle, you could have the UI just draw to the parent window via that | 04:17 |
| ColaEuphoria_ | Then you're neglecting DirectX/Vulkan | 04:18 |
| drobilla | One that can is, essentially by definition, happy with a native window handle, since that's what embedding is. See e.g. EGL which has native window pointers as well. | 04:18 |
| drobilla | damo22: Then you need to bake in an entire window API into the LV2 UI extension, to get the size and all the rest of it | 04:19 |
| drobilla | damo22: But hey, maybe. But if the host can do that, then so can the UI. At the end of the day the same thing needs to happen: you have an X window, you need to draw GL to it | 04:21 |
| drobilla | Adding a whole new UI interface for this just adds stability burden and gains nothing | 04:21 |
| drobilla | Requires all the hosts to implement it, yadda yadda, for no gain | 04:21 |
| * ColaEuphoria_ gets some tipsy motivation to work on nanogui/pugl | 04:21 | |
| *** hybrid has joined #lv2 | 04:22 | |
| drobilla | (Also I'm not sure WTF GL code they were talking about. Pugl doesn't draw anything...) | 04:22 |
| damo22 | maybe it was DPF stuff | 04:22 |
| drobilla | Maybe. or the cube test program, which is indeed awful (but irrelevant) | 04:23 |
| drobilla | A callback seems like a nice idea, but then all the hosts need to implement all the set up a GL context stuff | 04:24 |
| drobilla | For all platforms | 04:24 |
| drobilla | All of which already exists in portability libraries (like pugl and GLFW) | 04:24 |
| drobilla | and the native handle works just as well for non-GL things. It's universal. | 04:24 |
| drobilla | Really GLFW just needs fixing. | 04:24 |
| ColaEuphoria_ | Aren't native window handles also more stable than trying to cover rendering? | 04:24 |
| ColaEuphoria_ | Even when trying to get an OpenGL context there's a ton of options you have in terms of version# | 04:25 |
| drobilla | (Though I am not sure if it is plugin appropriate anyway, need to audit it for static crap) | 04:26 |
| drobilla | ColaEuphoria_: True. We lack configuration stuff entirely ATM, but most of it you can do later with GL calls themselves | 04:27 |
| drobilla | Of course, rendering is the easy part | 04:27 |
| drobilla | Events not so much. You need that window handle to get events and have any user interaction whatsoever | 04:28 |
| drobilla | So now to avoid that, we bake in an entire event API into the LV2 UI API | 04:28 |
| drobilla | aaaaaaaaaaand we've turned a single pointer to the reasonable thing into the bulk of a toolkit :) | 04:28 |
| ColaEuphoria_ | >An audio plug-in, in computer software, is a plug-in that can add or enhance audio-related functionality in a computer program. Such functionality may include digital signal processing or sound synthesis. | 04:40 |
| ColaEuphoria_ | :^) | 04:40 |
| drobilla | Anyway, talk is cheap. I'd be more than happy to be proven an asshole and for this *not* to be a misguided effort, by GLFW gaining the ability to embed. | 04:47 |
| drobilla | 'till then I'll be over here with my couple-KLOC wrapper that actually does the job | 04:50 |
| *** grejppi has quit IRC | 06:30 | |
| *** grejppi has joined #lv2 | 06:37 | |
| *** son0p has joined #lv2 | 08:25 | |
| *** son0p has quit IRC | 08:30 | |
| *** oofus_lt has joined #lv2 | 08:52 | |
| *** deva has joined #lv2 | 09:21 | |
| *** artfwo has quit IRC | 10:17 | |
| *** artfwo has joined #lv2 | 10:28 | |
| *** trebmuh has joined #lv2 | 10:29 | |
| *** edogawa has joined #lv2 | 10:47 | |
| *** ugjka is now known as UgJkA | 11:22 | |
| *** edogawa has quit IRC | 11:30 | |
| *** son0p has joined #lv2 | 11:32 | |
| *** oofus_lt has quit IRC | 11:49 | |
| *** oofus_lt has joined #lv2 | 11:52 | |
| *** son0p has quit IRC | 12:56 | |
| *** rncbc has joined #lv2 | 15:22 | |
| *** oofus_lt has quit IRC | 15:50 | |
| *** son0p has joined #lv2 | 15:53 | |
| *** oofus_lt has joined #lv2 | 16:00 | |
| * drobilla idly wonders what an LV2 package manager would look like | 16:01 | |
| rgareus | since bundles are self-contained, basically just curl + unzip | 16:14 |
| rgareus | unless you do want to include source-packages | 16:16 |
| drobilla | Well, you'd need a protocol to at least check/get particular versions, and a way to find current installed plugins, etc | 16:17 |
| drobilla | oh, and platform | 16:17 |
| drobilla | Providing a service that anyone can upload binaries to that are downloaded and executed is clearly trouble, though | 16:18 |
| rgareus | For mixbus plugin-update we use YYYYMMDD to describe bundles (a txt file, top-level of the custom LV2 search path) and uname. individual plugins have a version-number lilv picks the latest | 16:22 |
| rgareus | and yes, no public upload | 16:22 |
| drobilla | I guess just a mechanism to specify repositories to use. Maybe a default that includes known/trusted developers | 16:24 |
| rgareus | MOD is similar, no public upload | 16:24 |
| rgareus | you could gpg sign plugins and build a trust chain. | 16:25 |
| drobilla | It'd be pretty cool if everything could benefit from the same system | 16:25 |
| drobilla | install_a_bunch_of_cool_plugins_for_free_please would make LV2 a much more lucrative thing/contender | 16:26 |
| rgareus | like "your session misses plugin X, want me to download & install?" | 16:26 |
| drobilla | rgareus: I suppose, if we want to get fancy and support mirroring and whatnot like distros, but a simple thing where a given plugin comes from a given repository and its inherently trusted would do | 16:27 |
| *** rncbc has quit IRC | 16:40 | |
| *** rncbc has joined #lv2 | 16:41 | |
| *** Yruama_Lairba has joined #lv2 | 17:13 | |
| *** edogawa has joined #lv2 | 17:43 | |
| *** damo22 has quit IRC | 18:45 | |
| *** grejppi has quit IRC | 20:21 | |
| *** deva has quit IRC | 20:30 | |
| *** grejppi has joined #lv2 | 20:36 | |
| *** edogawa has quit IRC | 20:44 | |
| drobilla | I am wondering if some extension to state needs adding so that the plugin can tell if this is a "save" or a "preset save" | 21:05 |
| drobilla | This only makes sense for dynamic "plugins" like Ingen | 21:05 |
| drobilla | But I'm not sure how to figure out what to do | 21:05 |
| drobilla | I guess something like "if this graph has been saved elsewhere, and that save still exists, save a preset for it" | 21:06 |
| drobilla | Maybe with a symlink in the shared files dir for archiveability etc | 21:06 |
| *** edogawa has joined #lv2 | 21:09 | |
| drobilla | Allowing edits elsewhere to break a save is trouble, though | 21:09 |
| *** grejppi has quit IRC | 21:41 | |
| *** grejppi has joined #lv2 | 21:56 | |
| *** edogawa has quit IRC | 22:32 | |
| *** grejppi has quit IRC | 22:32 | |
| *** oofus_lt has quit IRC | 23:03 | |
| *** rncbc has quit IRC | 23:04 | |
| *** grejppi has joined #lv2 | 23:08 | |
| *** trebmuh has quit IRC | 23:19 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!