Thank you for your answer, as you said, this pattern makes things quite clear for the user. I like it :)
SDL is of course a somewhat special case, at it itself is an abstraction > over different backends, and there's little functionality there that could > not be part of a standard window API... > Yeah, that's true. But actually SDL is not even really a GUI / Windowing API. As stated ont heir website it is "[...]designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware [...]" So I guess it's the other way arround. You can probably do things with a real window API that you cannot do with SDL. What made me think of this "issue" is a new functionnality coming with the next version of SDL2 : https://wiki.libsdl.org/SDL_SetWindowHitTest I implemented this in OSWindow and then I asked myself if all the other libraries could do the same. I mean, it is always possible to move a window without decorations by using the mouse position and calls to "set window position" or whatever. Same goes for resizing. But the SDL way is so easy and painless that I wanted to know if the exact same way was doable with other libraries. After some basic researches on GTK+ I was not really able to tell if it was possible to do so. So a new question arose : Should I really look at every possible backend to know if a functionnality is general or backend-specific ? :/ 2015-06-16 12:15 GMT+02:00 Henrik Johansen <[email protected]>: > > On 16 Jun 2015, at 9:58 , Matthieu Lacaton <[email protected]> > wrote: > > Hello everybody, > > The question I have concerns OSWindow and its backend : SDL. However, even > if I'll speak about these two, i think the question is quite general and > can apply to every API. > > There are some functions that we are sure we will find in every backend > possible (for instance the possibility to create a new window, to resize it > etc.) and for these ones it is totally fine to abstract the backend from > the user because you know that even if the backend has to change the API > will be usable the same way. > > But there are some functions that are quite specific to a certain backend > and you cannot always find it in others. But this function is cool so it > would be a shame not to implement it just for the sake of uniformity. > In this case I see two options : > > 1) You abstract these functions exactly the same way you did for the > others and the user is not informed at all. In this case the risk is that > if the backend changes it may break the API for the user because he won't > be able to use this function anymore.And he may feel a bit sad because he > was not warned about it. > > 2) You make *something* to let the user know that this or that function > is specific to this or that backend. By doing so the user knows that there > is a small risk that he won't be able to use this function anymore if the > backend changes. He has been warned. > > Now I prefer the second option but I wanted to ask you about that > "something". What is the best way to warn the user ? > > - Should I let the name of the backend in the name of the method ? > "SDL_MySpecificMethod" > - Should I put all these methods in a specific package and name / comment > that package accordingly ? > - Some other things ? > > Basically my question is : what is the best way to let the user know he is > dealing with a specific function for a specific backend ? > > Thanks, > > Matthieu > > > A recent idea I had, translated to your case, was doing this by providing > accessors to specific backend extension classes. > Personally, I'd prefer to use a class separate from that which implements > the common interface, so one doesn't accidentally end up doing common calls > on only specific backends, here's a purely theoretical example of how that > may look: > > window := OSWindow new. > window title: 'Test window'. > "With SDL, we support making window unbordered" > window SDL bordered: false. > window openInWorld. > > With a few example implementations: > OSWindow >> #SDL > "Could cache in instvar, but that would not as modular, as you can't > package that with the rest of the backend, with methods all you need is > *SDL-Windows categorization" > currentBackEnd isSDL > ifTrue: [SDL_ExtWindow target: self] > ifFalse: [NoopWindow target: self] > > SDLExtendedWindow >> #bordered: aBoolean > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode> > ^ self nbCall: #( int SDL_SetWindowBordered ( SDL_Window * target , > SDL_bool aBoolean ) ) > > Haven't actually used this pattern yet, but at least to me, it yields a > clear distinction between what is common between backends, and what will > only work on some. > SDL is of course a somewhat special case, at it itself is an abstraction > over different backends, and there's little functionality there that could > not be part of a standard window API... > > Cheers, > Henry >
