* pancake [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
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 Maglione wrote:
On Mon, Sep 06, 2010 at 10:10:16PM +0200, Moritz Wilhelmy wrote:
Isn't portability one of the goals?
I don't
On Monday, September 6, 2010, Kris Maglione 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 extensions will
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 a
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 Sat, Sep 4, 2010 at 5:35 PM, pancake 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 manual:
-ffunctio
On Tue, Sep 07, 2010 at 12:00:27AM +0800, sqweek wrote:
On 4 September 2010 21:25, Uriel wrote:
On Sat, Sep 4, 2010 at 12:34 AM, Connor Lane Smith 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 l
On 4 September 2010 21:25, Uriel wrote:
> On Sat, Sep 4, 2010 at 12:34 AM, Connor Lane Smith 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 symbo
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.
- Original message -
> 2010/9/3 Connor Lane Smith :
> > > Oh, wait, you are creating a new library that uses those libraries!
> > > So
On Sat, Sep 4, 2010 at 12:34 AM, Connor Lane Smith 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 program.
uriel
On Friday, September 3, 2010, yy 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 understand what'
2010/9/3 Connor Lane Smith :
>> 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 the only o
On Friday, September 3, 2010, Uriel wrote:
> So instead you use libraries that already exist because OMG they are
> in Lunix!! (xlib and Xft, so far...)
Only Xlib, actually. And yes, using Unix libraries when on Unix seems
fairly logical.
> Oh, wait, you are creating a new library that uses thos
On Fri, Sep 3, 2010 at 10:28 AM, Connor Lane Smith 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!! (xlib and Xft
On Sep 3, 2010, at 8:19, Kurt H Maier 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:
http://prosourceindustrial.com/myPictures/duracellAA.jpg and that is
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,
+1 for libdc
On 09/03/10 10:48, Connor Lane Smith wrote:
On Friday, September 3, 2010, Anselm R Garbe 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 m
On Friday, September 3, 2010, Anselm R Garbe 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 name, what about
On 3 September 2010 10:28, Connor Lane Smith wrote:
> On Friday, September 3, 2010, Uriel 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
On Friday, September 3, 2010, Uriel 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 existed within dwm, dmen
On Fri, Sep 3, 2010 at 9:08 AM, Connor Lane Smith 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 'libdraw' is *bou
On Friday, September 3, 2010, Anders Andersson 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 that
> this is
>
> As far as I have seen from sporadically following this thread is that
> this is a library that tries to solve a personal issue for the author
> (writing text on a PDA/phone?). Since it can't draw stuff but insist
> on handling clipboards, maybe the name should reflect that.
>
So?
On Thu, Sep 2, 2010 at 11:51 PM, Kurt H Maier wrote:
> On Thu, Sep 2, 2010 at 4:26 PM, Uriel wrote:
>> On Wed, Sep 1, 2010 at 1:32 PM, Szabolcs Nagy wrote:
>>>[snip]
>>> the name could have been chosen with more care, but sane names
>>> are usually taken
>>
>> Except that in this case the name i
On Thu, Sep 2, 2010 at 4:26 PM, Uriel wrote:
> On Wed, Sep 1, 2010 at 1:32 PM, Szabolcs Nagy 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.
well l
On Wed, Sep 1, 2010 at 1:32 PM, Szabolcs Nagy 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
> sane names are usually taken
well, that's insane
* Uriel [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
> should be used as a
On Tuesday, August 31, 2010, Uriel wrote:
> libdraw should be: http://man.cat-v.org/p9p/3/draw and that is what
> should be used as a portable drawing backend, and if more
> functionality is needed, patches should be submitted to Russ.
No.
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
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 sou
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
should be used as a portable drawing backend, and if more
functionalit
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 width
On Tue, Aug 31, 2010 at 12:24 PM, v4hn 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 to read
shit
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 wo
On Monday, August 30, 2010, pancake 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 Anselm
to finalise
> Any feedback for this proposal? :)
Sounds good. :)
-sl
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 an
38 matches
Mail list logo
