Re: [dev] libdraw development

On Tue, Aug 31, 2010 at 08:53:02PM +0200, pancake wrote:
> I know that copypasting is probably not related to drawing, but
> afaik libdraw aims to be a [yet another] graphical backend API.

Well, if that's what it should be, then adding clipboard-support
is straightforward. However libdraw does sound like a suckless
library solving the problem of drawing on the screen, not the whole
problem of user interaction. And I suppose user interaction is,
where support for the clipboard is needed.

> As far as libdraw is distributed as a static library with one
> function per file it makes it good for adding more features without
> making resulting bins bigger.

Sure, the layout allows a lot of extensions..
But that doesn't imply the community should start writing
extensions for mouse-cursor handling, 3d-carved font rendering,
on-the-fly-translations while printing...

> In swk for example I'm implementing multiline text support which is
> in fact a text editor widget. The text manipulation functions are in
> text.c and I don't think a widget kit should provide a text
> processor. But where's the place for this? Libdraw maybe?

_If_ a wk includes multiline text support, then it has to include
some kind of text processor. But why should you propagate all editing
functions to the outside? Isn't it enough to provide one function
to initialize the text of the widget and one to read the content again?
Why does a _simple_ wk need to tell the program what happens while editing?
imho that's unneeded.
Another approach taken by e.g. lynx is to provide a way to open the
text in the multiline widget with $EDITOR if the user needs more
than the bare minimum of text handling implemented in the wk.

> Splitting each feature in different libs it makes the development
> harder (more dependencies).

Sure it does, yet specifying clearly what a library should provide
(and what it shouldn't provide) makes coding suckless easier.

In my opinion the domain of problems sselp addresses is simply to small
to make it a library on its own..
But on the other hand, if it's needed in a number of different
projects. Why not? One could still provide libdraw and 'libsselp'
as one package of suckless GUI libs.

v4hn