On Tue, 12 Nov 2013 17:47:26 -0800 Matthew Brush <mbr...@codebrainz.ca> wrote:
> On 13-11-12 10:43 AM, Dimitar Zhekov wrote: > > On Mon, 11 Nov 2013 01:31:35 -0800 > > Matthew Brush <mbr...@codebrainz.ca> wrote: > > > >>> 1. 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). > Slightly off-topic but Vala makes the async/GIO file stuff insanely easy > and short to write as it has support for it built right into the > language syntax. GLib-based, right? Well, at least we'll have only one (GIO) set of problems to worry about. > >>> 2. Language specific assistance, such as indentation, or dynamic error > >>> marking and intelligent autocompletes. [...] > >>> > >> > >> A way for plugins to "handle" certain filetypes so that plugins can be > >> loaded/unloaded as a filetype is used in a document and unload when no > >> documents currently use it or something. > > > > Nice idea, but why? It's not like they eat a lot of resources, and > > constantly (un)loading plugins has it's cost too. > > > > So they don't have to connect to every single document and notebook > signal and only activate themselves when a specific filetype is > opened/closed/saved/etc and de-activate themsleves when the tab switches > and stuff. Don't worry, gtk+3 will waste more time than all the current plugins together. > What's more it would/could provide some form of conflict > resolution over which plugins are handling which filetypes and stuff. > This is especially useful since we're talking about "language support > plugins", not run-of-the-mill existing Geany plugins which just (can) > stomp all over each other and Geany anyway :) We'll be lucky if these _future_ plugins provide so much functionality as to have conflicts over specific file types. > > The last time I checked, Geany + Scintilla with GTK+3 flickered on my > > machine. By the time they fix this, GTK+3 may drop or deprecate so many > > non-GNOME-3 features that I'll simply switch to Qt-based GUI. > > It works fine here with Scintilla, FWIW. You forgot the obligatory "YMMV". Should I make a video clip and post it? :) > GTK3 overall definitively feels > a little slower and some of the new "touch friendly" dialogs and stuff > are kind of annoying, but I mean barring completely switching toolkits > (unlikely) or writing our own cross-platform wrapper toolkit > (infeasible), it's what we're stuck with for the future, so why fight it > kicking and screaming? Because it's slower and annoying? Because we don't know what funny thing the gtk+ devs will do tommorow? The more I think about it, the more a transision to KDE seems a good idea. > >> 5. Drop Scintilla and use GtkSourceView. I'll just enumerate the reasons > >> that come to mind, in no particular order: > >> > >> [...] > > > > Nice points. But long time ago, I chose Geany specifically because it > > provided rectangular selections, and the GtkSourceView based editors > > did not - and still don't. Maybe in the next century?.. Of course, > > both rectangular selection and virtual space in Scintilla are > > afterthought and implemented as hacks, but they work. > > > > Yeah, and rectangular selection is definitively a valid point, but I > think we shouldn't rule out listing (on the wiki or wherever this > discussion winds up) the pros and cons of each and seeing what comes. The rectangular selection is a must have for me, as I'm using Geany for a general purpose editor as well. > We wouldn't have to use the latest greatest version of GtkSourceView, > although I don't see why not (assuming we're sticking with GTK+), since > that project is all about making a kick-ass powerful, flexible, GTK+ > friendly source code editing component. It's really disheartening to see it lacking features that the MS-DOS editors in the 80-s had. I mean it, no sarcasm here. > >> 6. Automatically-bindable plugin API that we officially support for > >> multiple languages. Writing plugins in C is crap, IMO. > > > > It depends on the need for speed. A GeanyInsertNum, GeanyExtraSel or > > Scope in <insert your favorite interpreter here> would be pointless. > > What does Scope do that it needs hard-core low-level speed for? The message loop and processing. > Or the other plugins? Nothing. After the rectangular selection was rewritten in Scintilla 2.x, it became so slow than even a shell script will not make any difference. -- E-gards: Jimmy _______________________________________________ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel