Le 15/11/2013 04:19, Matthew Brush a écrit :
On 13-11-14 10:56 AM, Dimitar Zhekov wrote:
On Tue, 12 Nov 2013 17:47:26 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
On 13-11-12 10:43 AM, Dimitar Zhekov wrote:
On Mon, 11 Nov 2013 01:31:35 -0800 Matthew Brush mbrush@codebrainz.ca wrote:
- An architecture that allows multi-threading to be used for non-GUI
tasks.
Another (perhaps more obvious) candidate here is file loading/saving, which is *way* easier than the parsing stuff since [...] and because Scintilla and GIO make this quite easy (probably wouldn't even require threads but just mainloop/async stuff).
We don't even have a proper saving with all GIO/GFile/whatever levels, because some people haven't completed even one level properly.
I didn't understand what this means?
We have several options to save a file in different ways, because all GLib stuff is either unreliable or has side effenct (owner and permissions change).
So fix GLib instead of adding a bunch of different workarounds to Geany. Geany's code isn't the place to work around bugs in the *open source*, supposedly cross-platform toolkit we use, it completely defeats the purpose of using such a library in the first place. If we can fix it Geany, we can just as easily contribute the fixes to GLib instead. If the fixes are too hackish or not good enough to be accepted in GLib, why would we want them in Geany's code?
Easier said than done unfortunately. The GIO problem about losing data on write failure has been discussed on their bug tracker, and the problem is that the fix isn't as obvious at it seems, and people didn't really agree on how it should be addressed. Unfortunately it didn't go much further AFAIK, and people started to use hacks and workarounds.