On 13-11-14 10:56 AM, Dimitar Zhekov wrote:
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).
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?
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.
Yes, and see above. (works fine for me though, YMMV)
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.
They definitively won't with all this completely counter-productive
hating on the library we use, holding back any type of useful progress
so you can vent your frustrations about something that is completely
outside of our control.
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? :)
I don't doubt it, I just said it works for me. I know of at least a few
other users and devs also using it without such problems.
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.
OK, but barring a switch to Qt, it's not at all useful gripe about how
much it sucks and cling to it in desperation, hoping some magical free
software gnome will come along and revert years worth of commits, made
on a corporation's dime, by people who seem to like the changes.
Lots of users actually *want* Geany to move to Gtk3, for various reasons
such as using the same theme as the rest of their desktop (see what Gtk
version the top 3 Linux distros are using) or to get better/any Wayland
or support, or for various other reasons.
So they shouldn't get proper support for their environment because you
hate change, refuse to acknowledge the inevitable and want to stick to a
deprecated version of our toolkit for a couple more years until it's
completely dead and gone and we are left with a big crusty hairball of
obsolete, unmaintainable source with more #ifdef's than actual lines of
code?
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.
It should definitively be taken into consideration if we do look at
switching in the future, as well as any other pros and cons.
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.
This hasn't changed between older and newer versions of GtkSourceView AFAIK.
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.
So you profiled it and found that the message loop was too slow and that
your "processing" was a big bottleneck?
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.
Scintilla openly accepts patches :)
FWIW, I'm not actually advocating that Gtk3 is better than Gtk2, I'm
advocating it doesn't change the fact that, for better or worse, Gtk3 is
the current version of our toolkit library (for quite some time now) and
complaining about it won't change anything.
Cheers,
Matthew Brush
_______________________________________________
Devel mailing list
Devel@lists.geany.org
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
