Tox, the distributed instant messaging program, just got a new GUI client that is written in PURE C WITHOUT ANY DIRTY TOOLKITS. Calls Xlib and the win32 api directly.
>>4 XCB couldn't be used, mainly because there isn't a way to draw unicode with it. xcb_image_text_16() is the closest thing there is, but isn't a proper approach. So, the choice was between Xlib or XCB+Cairo+Pango.
i wouldn't be surprised if wayland turns out to be as bad as X
Name:
Anonymous2014-06-23 13:55
>>6 Well, we have to support X for *Linux, *BSD, etc. And when Wayland becomes more popular, support for it can be added pretty quickly. The code is entirely portable, with folders for different windowing systems support (win32 and xlib folders). Adding wayland support should take no more than a week, if it's ever needed.
It's good to see new software being written in a real language. All these young punks are running around with their theories on their moral high horses, thinking about abstractions of other abstractions, and every five minutes they need to come up with a new language to brush all those layers under the rug. Shaking my head all the time at this nonsense. Any software not written in C is effectively dead on the table.
>>16 easy, select one or more: 1) by defining nothing in it 2) by adding __STDC_NO_GUI__ just like they did with threads in C11 3) by implementing the functions but making them fail (ex: window_t *window_create (void) { return NULL; })
Name:
Anonymous2014-06-23 15:39
>>15 Actually the only popular language that has a de jure standard UI toolkit is Java. Funnily enough, next to no one uses Java for GUIs (and of the few that do, many don't use the standard toolkit). The most popular language for writing GUIs is still C++, which has no standard toolkit. From this we conclude that any benefit of providing such a thing is ephemeral.
The most popular language for writing GUIs is still C++, which has no standard toolkit
soon
Let us take this opportunity to point and laugh at the standards committee. No one will use this because Qt already exists (as no one uses threads.h because pthreads already exists).
Actually the only popular language that has a de jure standard UI toolkit is Java
How about javashit with DOM/Html?
Didn't consider it, actually. ECMAScript could have been regarded as separate from HTML but these days I doubt that's true in practice.
and of the few that do, many don't use the standard toolkit
I am not a java user but why is this happening?
Because Swing is a hefty pile of shit and its widgets are non-native. Thus anyone who doesn't want to spend a ton of effort to make their application not look like some abortion from the mid 90s uses something else.
>>22 How is that post ``something smart to say''? Everyone knows HTML is shit, it adds nothing to the conversation and I'm just expressing a popular opinion.
>>26 Does ECMA has made any useful standard anyway? C# and the word's 2007 documents do not count
Name:
Anonymous2014-06-23 15:54
>>14 intN_t is the future, you need to accept that. Why care about the standard if the standard is shit?
Name:
Anonymous2014-06-23 15:55
>>29 Why not use (u)int_fastN_t? or even (u)int_leastN_t
Name:
Anonymous2014-06-23 16:02
>>30 Those names look horrible. If your compiler does not support "optional" sized types, you can always typedef them to int_leastN_t and get the same behaviour in most cases.
>>14 ~0 is enough to invoke undefined behavior. C99 supports both ones' complement and sign magnitude as well as two's complement. In a ones' complement machine, all-bits-set is a potential trap representation, as it represents the value you get when you evaluate negative zero.
You're supposed to have the equality -0 == 0. But ~0 == -0. So ~0 invokes undefined behavior. A fix would be ~0u.
>>28 Judging from http://en.wikipedia.org/wiki/List_of_Ecma_standards the answer to your question is "No." The only standards bodies that are worthy of any respect these days are IETF, IEEE, and ISO (though maybe not in that order).
>>29-31 Lots of code may rely on the limits of the exact width types for various things, so it's not a good idea in general to interchange leastN_t for N_t.
Nothing stops you from having your own int.h with stuff like
Because Swing is a hefty pile of shit and its widgets are non-native. Thus anyone who doesn't want to spend a ton of effort to make their application not look like some abortion from the mid 90s uses something else.
This is a bullshit complaint that only comes from Apple users. Don't be a fucking baby. Just reskin your widgets to have the right colors and you're done.
>>39 It is my opinion that Swing widgets, skinned or otherwise, look like shit on all platforms. Skinning just makes it less obvious. And why would you bother with skinning when you could just use something like Qt that looks OK on all platforms with no added effort?
>>43 You dickshit, this i) makes use of non standard functions (vasprintf) that is SLOWER than snprintf and even more slower than sprintf and you don't even make use of its output ii) INT_FAST8_MAX is not a type and you need to #include <stdint.h> first
But notsecure only uses ~0 only when assigning values to unsigned stuff. So there's no portability issue.
Concerning the int.h or a test macro to handle weird systems, I think he has other priorities, such as getting video working. Would you mind doing a pull request or posting the necessary changes in this thread? That would be pretty helpful.
Name:
Anonymous2014-06-23 17:19
so many autists antibumping
Name:
Anonymous2014-06-23 17:22
typedef uint8_t char_t;
WTHHH this is lame as hell, it uses uint8_t in a place where it is not needed (breaking comportability) and it violotates the POSIX standard (you can not define things that end with _t)
I don't really think the developer has time for this stuff right now, he is working of getting video, now that audio was added last week. Pull requests would surely make him happy, I believe. If you aren't in the mood, just keep complaining and I hope he eventually deal with all by himself.
>>57 I will be eagerly waiting. For some reason, it makes me happy seeing developers working together. It gets me almost moist. Something that I would love is it to compile without warnings, but there are so many of them, that I doubt it will ever be done.
Trivia: even most uTox's icons are written in C. svg is bloat. Eventually, it will all be C. Even notification sounds will be in C, probably some sine waves or something (can't remember the developer exact words).
>>71 Stop astroturfing, it's obvious you're the OP of this thread. You're risking a ban. We've had a few threads about Tox already, most of us just aren't interested in /g/ projects.
>>72 Sorry, I didn't know we had threads about it earlier, never saw one. Anyway, I am mostly talking about uTox, a Tox client. Not Tox itself. Sorry, Mr. Anonymous.
The tox developers are horrible people. They are ignorant and feel they are `competing' with the other open source telephony/chat alternatives. They are also making their users vulnerable by encouraging them to use a p2p software in pre alpha stage. The only software I will write for tox will be maleware. now please go away before I turn your wall paper in goatse.