50 most recent events by user js occurring on or after 2021-02-01 00:39:24.
More ↑
2021-04-07
| ||
18:44 | Rename OFEnumerating to OFEnumeration check-in: 151e4642fe user: js tags: trunk | |
18:38 | • Changes to wiki page "API Review for 1.0" artifact: 670d8744ba user: js | |
18:22 | • Changes to wiki page "API Review for 1.0" artifact: 7fb13efdd4 user: js | |
14:08 | • Changes to wiki page "API Review for 1.0" artifact: fa9f25d56e user: js | |
13:56 | • Added wiki page "API Review for 1.0" artifact: 1f7afe964a user: js | |
2021-04-05
| ||
21:31 | ofhttp: Fix finding ObjOpenSSL opportunistically check-in: e37212ea80 user: js tags: trunk | |
17:55 | socket.h: Add sa_family_t typedef on Windows check-in: 21a21f6a6b user: js tags: unix-sockets | |
16:30 | Add support for UNIX socket addresses check-in: 1db6618bb9 user: js tags: unix-sockets | |
2021-04-04
| ||
18:46 | Change -[contentsOfURLAtPath:] to return URLs check-in: 9135c5fcb8 user: js tags: trunk | |
13:25 | Rename +[pluginFromFile:] to +[pluginWithPath:] check-in: 45f8195351 user: js tags: trunk | |
2021-03-30
| ||
21:23 | Merge trunk into 1.0 branch check-in: 564d6d6b6f user: js tags: 1.0 | |
21:06 | Rename OFProcess to OFSubprocess check-in: 79548b3c29 user: js tags: trunk | |
2021-03-24
| ||
00:57 | *-x86-win32.S: Add .scl and .type check-in: 30ddefaf51 user: js tags: trunk | |
2021-03-23
| ||
23:57 | Remove -Wl,--default-image-base-low again check-in: 1ec5a2b219 user: js tags: trunk | |
23:07 | *-x86_64-win64.S: Add .scl and .type check-in: 7f7b2bbc90 user: js tags: trunk | |
2021-03-21
| ||
13:30 | Remove Travis support check-in: 4bc6412b3a user: js tags: trunk | |
2021-03-17
| ||
23:22 | OFINI*: Add -[description] check-in: 75d2dfa322 user: js tags: trunk | |
23:14 | OFINIFile: Add property containing all categories check-in: deebe3c034 user: js tags: trunk | |
00:14 | Work around crash on start with new MSYS2 check-in: dba770bccc user: js tags: trunk | |
2021-03-16
| ||
22:55 | Fix lookup-asm-x86_64-win64.S check-in: 4750a54072 user: js tags: trunk | |
21:16 | OFASN1*: Clean up the API a little check-in: ca9b843d37 user: js tags: trunk | |
2021-03-15
| ||
23:21 | • New ticket [55f58202d3] Write man pages for utils. artifact: a0f917e402 user: js | |
2021-03-14
| ||
23:54 | Convert lookup-asm-x86_64-win64.S to AT&T syntax check-in: 2fb21576da user: js tags: trunk | |
18:55 | ofhttp: Use "unnamed" if output name is nil or / check-in: 7b2c6a3873 user: js tags: trunk | |
12:23 |
•
Edit reply: GUI framework - call for help!
artifact: bc33cd24d9 user: js
For option 1 - 4, there needs to be a decision between Gtk and Qt. Here's some thought I have, but nothing is set in stone: Pros for Gtk:
Cons for Gtk:
Pros for Qt:
Cons for Qt:
Open questions for Qt:
| |
12:13 |
•
Reply: GUI framework - call for help!
artifact: 7d41e42d06 user: js
For option 1 - 4, there needs to be a decision between Gtk and Qt. Here's some thought I have, but nothing is set in stone: Pros for Gtk:
Cons for Gtk:
Pros for Qt:
Cons for Qt:
Anything else I forgot? | |
2021-03-13
| ||
18:44 |
•
Reply: GUI framework - call for help!
artifact: d39f77ce59 user: js
No worries about limited experience / knowledge. I'm personally happy to help. I’m happy to teach and delegate - this is a project for multiple people after all, so any time invested to get someone up to speed will be well worth it in the long run. On the chat, there is currently a preference for option 4 (the hybrid). I guess it makes sense, as it allows you to have a nice API and also break out of it if something is missing and hence might result in something usable quicker. But nothing is decided yet and you are the first one to commit to joining the effort 🙂. Let’s keep the discussion going and hope that more people are interested to help! | |
13:47 |
•
Post: GUI framework - call for help!
artifact: be2696fd72 user: js
tl;dr: ObjFW needs a GUI framework, there were several attempts in the past that failed, so we need to join forces. Please help, every little bit counts. One of the things that always comes up over all these years is a GUI framework for ObjFW. There have been several attempts, usually done by a single person, that then quickly died down because the work is overwhelming. This leaves us with the current situation that there is no ready-to-use GUI framework for ObjFW, despite it being one of the most requested things and the lack of a GUI framework probably being what holds back ObjFW adoption the most. It isn't beneficial to have so many projects for a GUI framework (see below) that all ultimately fail - instead, I want us to join forces, and come to a decision which option is the best one to move forward. Please comment on this thread which option you prefer and why, and whether you would be willing to help. Every little bit counts, so even if you think you will only contribute very little, please volunteer and reply here! OptionsThere are several approaches:
Option 1Option 1 is probably what has been attempted the most: There is adenosine with it's underlying atropine. There was GTKKit (it seems to have disappeared from GitHub, but luckily I forked it and that is still around). And there still is my own ObjQt. So there have been 3 attempts and none really got that far. Another problem they all share is that they currently need an extra thread or they block ObjFW's run loop. But that can be worked around by swizzling ObjFW's OFRunLoop to use the GUI toolkit's run loop. Option 2What all the attempts of option 1 have in common is that they were manually written bindings. I think this is what ultimately made them fail: The amount of work to create bindings manually is overwhelming and the toolkits grow at a faster pace than a single person can keep up with. Which brings us to option 2: Write a generator for an existing GUI toolkit. Gtk has gobject-introspection, Qt has something similar. There were brief looks into gobject-introspection, but that never went far. While it seems like a downside would be that this would have less adaptions for ObjC than option 1, this could be addressed by having tables that e.g. contain renames, manual overrides for certain methods/classes, etc. Option 3The downside of both of option 1 and 2 is that an existing GUI toolkit is not written around the dynamic nature of ObjC. Which brings us to option 3: Create a new, ObjC-native API, then implement it using one of the existing toolkits. The downside compared to option 1 and 2 is that it is a lot of work, and an additional downside to option 2 is that you can only use what has already been created and don't get a full GUI framework at once. This has been tried in ObjGUI, but I didn't do much on it. Option 4Which brings us to option 4, which is trying to get the best of both worlds: Follow option 1 or 2 to have bindings very close to the original toolkit, then write a wrapper that makes it more native (option 3) using the bindings from option 1 or 2. This allows breaking out of that more native wrapper to do things which aren't in the wrapper yet. As far as I know, this hasn't been tried yet. Option 5And finally, we have option 5, which is to create an entirely new GUI toolkit. The advantage is that you do not have to think about how to make an existing GUI toolkit play nice with ObjFW and that it is the most interesting option, as it allows you to create something new from scratch entirely instead of just creating a "boring" wrapper. Another advantage is of course that it could have very few dependencies, so that you can statically link it into your binary and get a single self-contained binary. And of course it will be more lightweight than both Gtk or Qt, so your static binary will not end up being gigantic. I did start this at some point (back then using Allegro as I did not want to create my own backend for every OS and since SDL2 was not a thing yet, and SDL1 can only handle one window), but never released anything. The huge disadvantage is of course that it will take time until you have all the things you need for an app and that it probably will not look native anywhere. I think this is more interesting for writing small utlility apps that you want to distribute easily rather than for apps that you want to use daily. Next stepsSo, first of all, since we already established that this is too much work for a single person, we need people who are interested in making a GUI framework for ObjFW a reality. So I would say that very first step would just be people shouting in this thread "Here, I'm interested!". Even if you can only contribute very little, please shout - every tiny bit helps! Once we have a group of interested people, we can discuss which of the options to pick and go from there, hopefully joining forces in the end fo make a single GUI framework succeed instead of having many single person projects that fail. And please feel free to hop into the chat at any time to discuss as well. | |
2021-03-11
| ||
01:10 | tests: Fix missing \r check-in: 0fe7c59492 user: js tags: trunk | |
2021-03-08
| ||
00:07 | src/Makefile: Indentation fix check-in: b87baa7fd6 user: js tags: 1.0 | |
00:04 | Make GCC happy again check-in: eb328735f2 user: js tags: trunk | |
00:00 | Make +[stringWithContentsOfURL:] always available check-in: 1a49ef773d user: js tags: trunk | |
2021-03-07
| ||
20:25 | *.m: Fold methods into one line where it fits check-in: 1b82d3bf4f user: js tags: trunk | |
15:07 | *.h: Fold methods into one line where it fits check-in: 1948e7e972 user: js tags: trunk | |
02:36 | Style change: Allow more than 1 argument per line check-in: a0fd103a0b user: js tags: trunk | |
01:53 | Remove useless *Value from selector names check-in: b0b5eff396 user: js tags: trunk | |
2021-02-28
| ||
23:42 | OFINICategory: Documentation fixes check-in: b5afddbea4 user: js tags: trunk | |
23:25 | OFWindowsRegistryKey: More accurate method names check-in: 7c83502291 user: js tags: trunk | |
15:22 | More consistent API for OFINICategory & OFSettings check-in: 2ed9cbdc0c user: js tags: trunk | |
2021-02-22
| ||
22:38 | lookup-asm-x86*.S: Minor optimization check-in: ddc5d6ac49 user: js tags: trunk | |
2021-02-17
| ||
23:02 | README.md: Add back the Gitter room check-in: a498cfaf93 user: js tags: trunk | |
2021-02-08
| ||
02:16 | Revert lookup-asm-x86-elf.S back to AT&T syntax check-in: 5bf7a7f7ba user: js tags: trunk | |
02:08 | Revert call-x86_64-elf.S back to AT&T syntax check-in: 541b66cc87 user: js tags: trunk | |
02:04 | Revert apple-call-x86_64.S back to AT&T syntax check-in: adc1dedc5f user: js tags: trunk | |
02:01 | Revert forwarding-x86-elf.S back to AT&T syntax check-in: 0ce474546f user: js tags: trunk | |
2021-02-07
| ||
18:34 | Revert forwarding-x86_64-elf.S back to AT&T syntax check-in: da13b10211 user: js tags: trunk | |
18:25 | Revert forwarding-x86_64-win64.S to AT&T syntax check-in: 491a164ab6 user: js tags: trunk | |
01:05 | Revert forwarding-x86-win32.S back to AT&T syntax check-in: 82bfdb5575 user: js tags: trunk | |
00:59 | Revert forwarding-x86_64-macho.S to AT&T syntax check-in: 5277d2b62a user: js tags: trunk | |
2021-02-01
| ||
00:39 | Revert lookup-asm-x86-win32.S back to AT&T syntax check-in: 603524c162 user: js tags: trunk | |