On Monday, September 6, 2010, Kris Maglione maglion...@gmail.com wrote:
On Mon, Sep 06, 2010 at 10:10:16PM +0200, Moritz Wilhelmy wrote:
Isn't portability one of the goals?
I don't use that kind of GNU extension gunk so I split my files anyway.
Indeed. The day suckless software depends on GNU
Another hacky option is to embed all functions in .h include files as
'static inline'.
On 09/07/10 16:44, Connor Lane Smith wrote:
On Monday, September 6, 2010, Kris Maglionemaglion...@gmail.com wrote:
On Mon, Sep 06, 2010 at 10:10:16PM +0200, Moritz Wilhelmy wrote:
Isn't portability one
* pancake panc...@youterm.com [2010-09-07 16:49:20 +0200]:
Another hacky option is to embed all functions in .h include files
as 'static inline'.
then you'd have to include all code in the .h which would
make compilation slow whereever draw.h is included
the separate files are fine
On Tue, Sep 07, 2010 at 12:00:27AM +0800, sqweek wrote:
On 4 September 2010 21:25, Uriel ur...@berlinblue.org wrote:
On Sat, Sep 4, 2010 at 12:34 AM, Connor Lane Smith c...@lubutu.com wrote:
One file per function means a binary will only link the objects it
needs, which helps keep binary size
On Sat, Sep 4, 2010 at 5:35 PM, pancake panc...@youterm.com wrote:
Function per file is because the stupid gnu linker does not statically
compile functions. Only objects. Afaik. This way the resulting bin can be
smaller.
gcc has -ffunction-sections and ld has -gc-sections.
From the gcc
Hello,
Why not just split it, like everybody else does? Plus, other compilers
possibly don't support it. I't quite a convention for libraries, as far as I
know. Instead, you make it work only with gcc, something you usually complain
about as big and sucky that has more fuss than necessary
On Mon, Sep 06, 2010 at 10:10:16PM +0200, Moritz Wilhelmy wrote:
Why not just split it, like everybody else does? Plus, other
compilers possibly don't support it. I't quite a convention
for libraries, as far as I know. Instead, you make it work
only with gcc, something you usually complain
On Sat, Sep 4, 2010 at 12:34 AM, Connor Lane Smith c...@lubutu.com wrote:
One file per function means a binary will only link the objects it
needs, which helps keep binary size down when statically linking
The linker should be capable of including only the symbols that are
actually used in the
On Friday, September 3, 2010, Anders Andersson pipat...@gmail.com wrote:
Since this library doesn't seem to have much to do with drawing
anyway, I fail to see why it should pollute the already taken and very
generic 'libdraw'.
As far as I have seen from sporadically following this thread is
On Fri, Sep 3, 2010 at 9:08 AM, Connor Lane Smith c...@lubutu.com wrote:
Things are better seen in black and white, as Uriel will no doubt agree.
Its got nothing to do with black and white: retarded shit is retarded.
Unless you are a postmodernist, in which case any turd goes.
Using the name
On Friday, September 3, 2010, Uriel ur...@berlinblue.org wrote:
I understand that when you are busy reinventing square wheels, causing
extra confusion is the least of your worries...
Clearly you didn't read the explanation of what libdraw is... Allow me
to reiterate: the functions already
On 3 September 2010 10:28, Connor Lane Smith c...@lubutu.com wrote:
On Friday, September 3, 2010, Uriel ur...@berlinblue.org wrote:
I understand that when you are busy reinventing square wheels, causing
extra confusion is the least of your worries...
Clearly you didn't read the explanation of
On Friday, September 3, 2010, Anselm R Garbe garb...@gmail.com wrote:
Plan 9's libdraw is very different to the libdraw we are discussing.
libdraw of dmenu/dwm is intended to be used for different backends,
not just xlib, hence having libxdraw would be misleading. If we think
about a better
WTF is this 'libdc' thing? So are you guys not only duplicating
existing functionality implemented by batteries, but you are also
confusingly using the same names?
libdc should be:
http://prosourceindustrial.com/myPictures/duracellAA.jpg and that is
what
should be used as a power drawing backend,
On Sep 3, 2010, at 8:19, Kurt H Maier karmaf...@gmail.com wrote:
WTF is this 'libdc' thing? So are you guys not only duplicating
existing functionality implemented by batteries, but you are also
confusingly using the same names?
libdc should be:
On Fri, Sep 3, 2010 at 10:28 AM, Connor Lane Smith c...@lubutu.com wrote:
It may just be me, but weren't we
trying to write simple software, not just use libraries that already
exist because OMG they're in Plan 9!
So instead you use libraries that already exist because OMG they are
in Lunix!!
2010/9/3 Connor Lane Smith c...@lubutu.com:
Oh, wait, you are creating a new library that uses those libraries! So
I guess that makes it all OK. Not.
You are aware P9P's libdraw depends on Xlib?
It doesn't. libdraw uses a custom protocol to speak with devdraw,
which is a separate program and
On Friday, September 3, 2010, yy yiyu@gmail.com wrote:
It doesn't. libdraw uses a custom protocol to speak with devdraw,
which is a separate program and the only one in p9p which really
depends on xlib.
I'd still consider that a dependency, but a bit crazier. But fair
enough I guess?
I
On Wed, Sep 1, 2010 at 1:32 PM, Szabolcs Nagy n...@port70.net wrote:
[snip]
the name could have been chosen with more care, but sane names
are usually taken
Except that in this case the name is both insane *and* already taken
by a sane library.
uriel
On Thu, Sep 2, 2010 at 11:51 PM, Kurt H Maier karmaf...@gmail.com wrote:
On Thu, Sep 2, 2010 at 4:26 PM, Uriel ur...@berlinblue.org wrote:
On Wed, Sep 1, 2010 at 1:32 PM, Szabolcs Nagy n...@port70.net wrote:
[snip]
the name could have been chosen with more care, but sane names
are usually
* Uriel ur...@berlinblue.org [2010-08-31 23:21:54 +0200]:
WTF is this 'libdraw' thing? So are you guys not only duplicating
existing functionality implemented by p9p, but you are also
confusingly using the same names?
libdraw should be: http://man.cat-v.org/p9p/3/draw and that is what
sane names are usually taken
well, that's insane
On Monday, August 30, 2010, pancake panc...@youterm.com wrote:
I also liked to know if the libdraw author is open to contributions (can I
commit
it directly?).
Yes, except, libdraw is currently waiting to be released as version
0.1, and ofc development would destabilize it. I'm waiting for
ok,
you're a great programmer as far a I can see,
so don't take the following personally.
I suppose I _kind of_ get why you're proposing such things,
but excuse me?? What is wrong with you?
On Mon, Aug 30, 2010 at 06:44:36PM +0200, pancake wrote:
I would like to have functions in libdraw to
On Tue, Aug 31, 2010 at 12:24 PM, v4hn m...@v4hn.de wrote:
What's the connection between support for X clipboard and _simple drawing_?
if you want to select text, libdraw is going to need to be able to
load shit in to the clipboard
if you want to paste text, libdraw is going to need to be able
I know that copypasting is probably not related to drawing, but afaik
libdraw aims to be a graphical backend API.
It works with text, colors and not many things more. There's no
functions to draw pixels, lines, circles, pixmaps, etc..
But it does for font loading and measuring of char
TODO
Not having these would probably suck:
- libcppst; for copying and pasting
- perhaps in the future: libdrgndrp; for dragging and dropping
- definitely a libwimp; for the icons
Good night, I'm going to dream about OpenGL now :D
Recently I've been writing the X11 backend of swk, the suckless widget
kit.
After some lines of code I noticed that i was redoing stuff already done by
other projects and also in libdraw.. So I started mixing raw X code with
libdraw..
Actually I'm hacking in 'st' in order to add clipboard
Any feedback for this proposal? :)
Sounds good. :)
-sl
29 matches
Mail list logo
