Re: [Geany-Devel] splitwindow2
Hi Thomas, I havn't had a chance to use it yet, but I've looked at it, and have left a few comments on the github code. Certainly at this prototype stage its pretty simple :) Cheers Lex ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] splitwindow2
Am 11.10.2013 07:01, schrieb Matthew Brush: notebooks. 99% of the now hardcoded places will work fine, e.g. I'm using gtk_widget_get_parent(sci) to get a doc's notebook and implement a foreach_notebook() macro. So this should make it really trivial to support even more than 2 notebooks. gtk_widget_get_parent(sci) makes a big assumption; that the Scintilla will be packed directly into a notebook. Plugins can easily break this assumption by reparenting the Scintilla widget, and even my document-messages branch moved each Scintilla into a VBox inside each tab so it could pack a GtkInfo bar above it. I think we could get rid of this assumption by designing the code better. Okay, I have written a function that walks the tree to find the parent notebook. So this assumption is no more. Thanks for the hint. Please don't write another foreach_ macro. Lets make it so we can use normal C code. If you need a macro like foreach_notebook() it's probably because the code it's hiding is crappy underlying code, IMO. I like foreach_*, and many other people do. I guess it's subjective. Plus it will make the transition from main and secondary notebook to array of N notebooks easier. But still, I personally don't have a need for more than 2 notebooks. Plus I see it will be difficult to support, because you need to nest GtkPaneds. Since you suggest arbitrary splits you can do this only programmatically which sounds like a major headache to me (especially w.r.t. saving/restoring state). For now I want to concentrate on lifting the hardcoded single notebook without ending up in the same situation for two ones and without worrying about the heavy case of arbitrary notebook placing. Then we can continue from there on with more sophisticated stuff. However if you have already successfully implemented this in a toy editor I welcome you to join the fun. Just to be clear, regarding the split window feature in my toy editor, I only coded the UI logic, not any of the storing config of what panes were open or what documents they had in them and more complicated stuff like this. But the UI was indeed quite neat. SublimeText also has a similarly flexible split pane system. Okay, so you stopped ater the easy parts :P All of those functions in document_ module shouldn't care the least about GTK+ or even notebooks, IMO. This is the type of stuff I want to cleanup. There are also many direct uses of main_widgets.notebook, changing these might (or might not) affect plugins. IMO, if you're going to break the plugin API anyway, I say make it good and we'll fixup core and GP plugins and make a message on the mailing list for other users to know what broke and how to fix it in their own personal plugins. It's not yet clear to me how bady (or if at all) the API is going to break.. I already have an experimental version up and running that doesn't even require all that much changes[1] and it seems to work nicely. See this[2] screenshot. IMO, least amount of changes is not necessarily a virtue, and can even lead to further gluing of the code together making future changes even harder. But it's better than not getting the job done at all because people want to much at once. So, any opinions? It sounds like you already are planning some of this, but it would be nice to cleanup a lot of the assumptions/hardcoded stuff/weirdness while making these fairly intrusive changes. For example: - The relationship between documents and notebooks they're in, as you discussed. As Lex mentioned, it would be nice to not make too much new hard-coded assumptions about other documents only being allowed in another notebook, but rather making it extensible to support multiple windows in the future. Also as I mentioned, it would be nice to not make any hard-coded assumptions about only having two split notebooks[1]. gtk_widget_get_parent(doc-editor-sci) without hardcoding. I'm using this where possible. You're still hardcoding, just a different assumption as mentioned above. The notebook of a doc can be retrieved via - The relationship between documents (models) and Scintilla (views), they should be almost completely independent. There shouldn't need to have document-editor-scintilla, the document needn't care what view it's in, only the reverse. I have no idea where GeanyEditor fits into this, I've never understood why it exists; it's not a view, it's not a model, and it's not really a controller either, it's like part wrapper over Scintilla, part extension of GeanyDocument or something like this I guess? Sorry, I think this item is out of scope for this work. FWIW, I don't quite understand the deal about GeanyEditor either. It's not out of scope, but it is way more work than I think you're personally prepared to do. It's basically the reason no one fixed the split window before or worked to moving it into core, because it was too much work with the current way it's
Re: [Geany-Devel] splitwindow2
On 13-10-11 02:23 AM, Thomas Martitz wrote:
Am 11.10.2013 07:01, schrieb Matthew Brush:
notebooks. 99% of the now hardcoded places will work fine, e.g. I'm
using gtk_widget_get_parent(sci) to get a doc's notebook and implement a
foreach_notebook() macro. So this should make it really trivial to
support even more than 2 notebooks.
gtk_widget_get_parent(sci) makes a big assumption; that the Scintilla
will be packed directly into a notebook. Plugins can easily break this
assumption by reparenting the Scintilla widget, and even my
document-messages branch moved each Scintilla into a VBox inside each
tab so it could pack a GtkInfo bar above it. I think we could get rid
of this assumption by designing the code better.
Okay, I have written a function that walks the tree to find the parent
notebook. So this assumption is no more. Thanks for the hint.
You don't need to walk any tree's, if you need to notebook from the
scintilla, just store a pointer to the notebook in the scintilla, ex.
using g_object_set_data() or more painfully by subclassing it.
Please don't write another foreach_ macro. Lets make it so we can use
normal C code. If you need a macro like foreach_notebook() it's
probably because the code it's hiding is crappy underlying code, IMO.
I like foreach_*, and many other people do. I guess it's subjective.
Plus it will make the transition from main and secondary notebook to
array of N notebooks easier.
What's the problem with just using C code?
for (size_t i=0; i notebooks_arr-len; i++) {
// just normally use elements in the GPtrArray (as example)
}
Such macros not only make for weird APIs but also do weird stuff with
arguments since it's just textual replacements.
But still, I personally don't have a need for more than 2 notebooks.
Plus I see it will be difficult to support, because you need to nest
GtkPaneds. Since you suggest arbitrary splits you can do this only
programmatically which sounds like a major headache to me (especially
w.r.t. saving/restoring state). For now I want to concentrate on lifting
the hardcoded single notebook without ending up in the same situation
for two ones and without worrying about the heavy case of arbitrary
notebook placing. Then we can continue from there on with more
sophisticated stuff.
However if you have already successfully implemented this in a toy
editor I welcome you to join the fun.
Just to be clear, regarding the split window feature in my toy editor,
I only coded the UI logic, not any of the storing config of what panes
were open or what documents they had in them and more complicated
stuff like this. But the UI was indeed quite neat. SublimeText also
has a similarly flexible split pane system.
Okay, so you stopped ater the easy parts :P
Yep :)
All of those functions in document_ module shouldn't care the least
about GTK+ or even notebooks, IMO. This is the type of stuff I want to
cleanup.
There are also many direct uses of main_widgets.notebook, changing these
might (or might not) affect plugins.
IMO, if you're going to break the plugin API anyway, I say make it
good and we'll fixup core and GP plugins and make a message on the
mailing list for other users to know what broke and how to fix it in
their own personal plugins.
It's not yet clear to me how bady (or if at all) the API is going to
break..
I already have an experimental version up and running that doesn't
even
require all that much changes[1] and it seems to work nicely. See
this[2] screenshot.
IMO, least amount of changes is not necessarily a virtue, and can even
lead to further gluing of the code together making future changes even
harder.
But it's better than not getting the job done at all because people want
to much at once.
Yeah, but I wonder. Sometimes just patching on more changes adds to the
number of bugs and code weirdness at least as much as just refactoring
the code being patched on to. Of course if you just want to tack on a
quick feature this is desirable, but if you want to improve the overall
code quality, it's arguable.
So, any opinions?
It sounds like you already are planning some of this, but it would be
nice to cleanup a lot of the assumptions/hardcoded stuff/weirdness
while making these fairly intrusive changes. For example:
- The relationship between documents and notebooks they're in, as you
discussed. As Lex mentioned, it would be nice to not make too much new
hard-coded assumptions about other documents only being allowed in
another notebook, but rather making it extensible to support multiple
windows in the future. Also as I mentioned, it would be nice to not
make any hard-coded assumptions about only having two split
notebooks[1].
gtk_widget_get_parent(doc-editor-sci) without hardcoding. I'm using
this where possible.
You're still hardcoding, just a different assumption as mentioned above.
The notebook of a doc can be retrieved via - The relationship
between documents
Re: [Geany-Devel] splitwindow2
Am 11.10.2013 12:07, schrieb Matthew Brush:
On 13-10-11 02:23 AM, Thomas Martitz wrote:
Am 11.10.2013 07:01, schrieb Matthew Brush:
notebooks. 99% of the now hardcoded places will work fine, e.g. I'm
using gtk_widget_get_parent(sci) to get a doc's notebook and
implement a
foreach_notebook() macro. So this should make it really trivial to
support even more than 2 notebooks.
gtk_widget_get_parent(sci) makes a big assumption; that the Scintilla
will be packed directly into a notebook. Plugins can easily break this
assumption by reparenting the Scintilla widget, and even my
document-messages branch moved each Scintilla into a VBox inside each
tab so it could pack a GtkInfo bar above it. I think we could get rid
of this assumption by designing the code better.
Okay, I have written a function that walks the tree to find the parent
notebook. So this assumption is no more. Thanks for the hint.
You don't need to walk any tree's, if you need to notebook from the
scintilla, just store a pointer to the notebook in the scintilla, ex.
using g_object_set_data() or more painfully by subclassing it.
That pointer needs to be updated properly when the doc is moved. I
rather save that and walk the tree, it's cheap enough.
(g_object_get_data() is a hash-table lookup which isn't exactly free either)
Please don't write another foreach_ macro. Lets make it so we can use
normal C code. If you need a macro like foreach_notebook() it's
probably because the code it's hiding is crappy underlying code, IMO.
I like foreach_*, and many other people do. I guess it's subjective.
Plus it will make the transition from main and secondary notebook to
array of N notebooks easier.
What's the problem with just using C code?
for (size_t i=0; i notebooks_arr-len; i++) {
// just normally use elements in the GPtrArray (as example)
}
Such macros not only make for weird APIs but also do weird stuff with
arguments since it's just textual replacements.
There is no notebooks_arr in the current code. Instead there is a
macro which makes it easy to transition to such an array later on.
Seriously, if foreach_* macros are so frowned upon, why is Geany still
full of them? I'm literally just following existing Geany-style with
that macro.
I personally like these macros, they are easy to understand and nicely
short. I've also seen them used in other projects.
The notebook of a doc can be retrieved via - The relationship
between documents (models) and Scintilla (views),
they should be almost completely independent. There shouldn't need to
have document-editor-scintilla, the document needn't care what view
it's in, only the reverse. I have no idea where GeanyEditor fits into
this, I've never understood why it exists; it's not a view, it's
not a
model, and it's not really a controller either, it's like part
wrapper
over Scintilla, part extension of GeanyDocument or something like
this
I guess?
Sorry, I think this item is out of scope for this work. FWIW, I don't
quite understand the deal about GeanyEditor either.
It's not out of scope, but it is way more work than I think you're
personally prepared to do. It's basically the reason no one fixed the
split window before or worked to moving it into core, because it was
too much work with the current way it's coded. If this kind of stuff
gets cleaned up first, the split window thing becomes trivial (as well
as multi-window, etc). I would've fixed up split window myself 10x by
now if I didn't morally have to cleanup all this code to do it
correctly.
See, if you make this kind of cleanup a hard requirement that no
progress is going to happen, for the reasons you mention. Can't we just
progress with managable portions of cleanups/workload, considering our
already heavily limited developer manpower?
Yep, that's why my previous message, I'll try not to interfere here
too much since no one is interested in the type of stuff I'm talking
about probably (cleanup up the code en masse).
I would still love to collaborate with you and other devs, even if I'm
not going to make the uncertain (for me, anyway) big cleanup personally.
The cleanup you propose would be impossible for me to do anyway, because
I have no vision how the end result would look like. Without such a
vision I wouldn't know where to start and where to end. As I said, I
don't know about the GeanyEditor deal but I don't have a problem with it
either. And splitwindow can be done with the current structures. So I
maintain that your proposal is out of scope for my work. The same goes
for your other cleanup proposals.
The patterns and paradigms used in IDE software and editors are not
new, we aren't paving new ground here, usually we're just fighting it
by not using the tools at our disposal for artificial reasons (totally
off-topic).
Loose statement, see below.
- Encapsulating the GeanyDocument so that plugins can't mess with
read-only members. For example, it makes no
Re: [Geany-Devel] splitwindow2
Le 10/10/2013 12:03, Thomas Martitz a écrit : Hello, I just wanted to let you know that I'm working on a new splitwindow implementation and I would like to have early input. [...] I don't have time yet to fully get down to the complicated discussion this went on, but I just wanted to point out I did a little refactoring of the splitwindow plugin some time ago, see https://github.com/b4n/geany/tree/splitwindow-refactoring-m The UI isn't nice and it's why I didn't merge it yet, but it makes the split view effectively useable. In practice, what it does is very simple: make sure whatever view you're touching it's actually always the primary Geany one, so it removes any need problem coming from Geany hardcoding some stuff. Regards, Colomban ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] splitwindow2
On 13-10-11 03:29 AM, Thomas Martitz wrote:
Am 11.10.2013 12:07, schrieb Matthew Brush:
On 13-10-11 02:23 AM, Thomas Martitz wrote:
Am 11.10.2013 07:01, schrieb Matthew Brush:
notebooks. 99% of the now hardcoded places will work fine, e.g. I'm
using gtk_widget_get_parent(sci) to get a doc's notebook and
implement a
foreach_notebook() macro. So this should make it really trivial to
support even more than 2 notebooks.
gtk_widget_get_parent(sci) makes a big assumption; that the Scintilla
will be packed directly into a notebook. Plugins can easily break this
assumption by reparenting the Scintilla widget, and even my
document-messages branch moved each Scintilla into a VBox inside each
tab so it could pack a GtkInfo bar above it. I think we could get rid
of this assumption by designing the code better.
Okay, I have written a function that walks the tree to find the parent
notebook. So this assumption is no more. Thanks for the hint.
You don't need to walk any tree's, if you need to notebook from the
scintilla, just store a pointer to the notebook in the scintilla, ex.
using g_object_set_data() or more painfully by subclassing it.
That pointer needs to be updated properly when the doc is moved. I
Yep, but it's one single place this could happen.
rather save that and walk the tree, it's cheap enough.
(g_object_get_data() is a hash-table lookup which isn't exactly free
either)
O(1) is pretty OK to me :)
I actually don't think they use hash table for GObject data lists
though, rather it's probably some type of binary tree or such but it's
still relatively cheap lookup.
Please don't write another foreach_ macro. Lets make it so we can use
normal C code. If you need a macro like foreach_notebook() it's
probably because the code it's hiding is crappy underlying code, IMO.
I like foreach_*, and many other people do. I guess it's subjective.
Plus it will make the transition from main and secondary notebook to
array of N notebooks easier.
What's the problem with just using C code?
for (size_t i=0; i notebooks_arr-len; i++) {
// just normally use elements in the GPtrArray (as example)
}
Such macros not only make for weird APIs but also do weird stuff with
arguments since it's just textual replacements.
There is no notebooks_arr in the current code. Instead there is a
macro which makes it easy to transition to such an array later on.
? I mean to just literally use a real GPtrArray of notebooks, instead of
just toggling between a fixed two of these containers.
Seriously, if foreach_* macros are so frowned upon, why is Geany still
full of them? I'm literally just following existing Geany-style with
that macro.
I personally like these macros, they are easy to understand and nicely
short. I've also seen them used in other projects.
I don't doubt it, but what really does it gain over just putting the
literal C code? If you are repeating it so much, refactor your code,
otherwise, it's just normal part of C. Mutilating C with the
preprocessor quite often does not improve the clarity of usability of code.
The notebook of a doc can be retrieved via - The relationship
between documents (models) and Scintilla (views),
they should be almost completely independent. There shouldn't need to
have document-editor-scintilla, the document needn't care what view
it's in, only the reverse. I have no idea where GeanyEditor fits into
this, I've never understood why it exists; it's not a view, it's
not a
model, and it's not really a controller either, it's like part
wrapper
over Scintilla, part extension of GeanyDocument or something like
this
I guess?
Sorry, I think this item is out of scope for this work. FWIW, I don't
quite understand the deal about GeanyEditor either.
It's not out of scope, but it is way more work than I think you're
personally prepared to do. It's basically the reason no one fixed the
split window before or worked to moving it into core, because it was
too much work with the current way it's coded. If this kind of stuff
gets cleaned up first, the split window thing becomes trivial (as well
as multi-window, etc). I would've fixed up split window myself 10x by
now if I didn't morally have to cleanup all this code to do it
correctly.
See, if you make this kind of cleanup a hard requirement that no
progress is going to happen, for the reasons you mention. Can't we just
progress with managable portions of cleanups/workload, considering our
already heavily limited developer manpower?
Yep, that's why my previous message, I'll try not to interfere here
too much since no one is interested in the type of stuff I'm talking
about probably (cleanup up the code en masse).
I would still love to collaborate with you and other devs, even if I'm
not going to make the uncertain (for me, anyway) big cleanup personally.
Yeah, the big cleanup is more of a pipe/future dream for me I guess, so
I'll just contribute and help out normally rather than get too
Re: [Geany-Devel] splitwindow2
Am 11.10.2013 13:12, schrieb Matthew Brush: I just mean that the study of such applications is not new, like some canonical texts such as http://en.wikipedia.org/wiki/Design_Patterns, specifically 2.1. We also have all of those that came before, like borland, ms, anjuta, vim, emacs, eclipse, gedit, mousepad, netbeans, qtcreator, xcode, and 42.0 billion more examples, many of which we can study their source code or even overall architecture and see some good/bad ways to code stuff. For something more concrete, maybe take Cocoa's document architecture; https://developer.apple.com/library/mac/documentation/DataManagement/Conceptual/DocBasedAppProgrammingGuideForOSX/Introduction/Introduction.html It might not be Geany-style C, but a lot these ideas are known and used elsewhere, probably even inherited from the first link. I just suggest we could copy some of them too, rather than looser ad-hoc coding :) I think you should formulate your specific vision for Geany, perhaps on the wiki or so. It doesn't help me if you list projects or books which I could possibly look at (which I'm not gonna do because it would take ages to grasp their model and consider advantages and disadvantages) because I don't know what's so horrible about status quo. As a result I lack motivation to evaluate alternatives. Best regards. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Drop GtkStock and use symbolic icons
On Fri, 11 Oct 2013 02:14:59 +0200 Yosef Or Boczko yosef...@gmail.com wrote: The icons in Stock is icons in some sizes, not SVG. GTK_ICON_SIZE_* do not specify any hardcoded pixel sizes. You can patch Geany with GTK_ICON_LOOKUP_FORCE_SVG, if you want. The symbolic icons is SVG, better polished. A common misconception. An SVG icon in today's 100-120 DPI displays may look better, or worse. Google for TTF hinting, and consider that there is *no* hinting for SVG. If the vector icons were always better, PNG-s in specific sizes would have been deleted long time ago. Note: also for the symbolic icons have a themes. The stock icons are entirely theme dependent. As I sad: „The icons in the menus and in the buttons in the dialogs isn't add any information. I not think the 'OK' icon is add information there isn't in the string „Save”.” You cite yourself as if your personal opinion is somehow more valuable than anyone else's opinion. GTK+ 2.24.0 released in 2011, soon we are in 2014. Debian stable + testing: Packages dependent on GTK+ 2.24: 1930. Packages dependent on GTK+ 3.8: 676. Also the widgets with image in a menu is deprecated (GtkImageMenuItem, for example), and also the function to create a buttons with Stock item is deprecated (gtk_button_new_from_stock() and gtk_image_new_from_stock() for example). What's next, no menus and window titles because of the mobile devices? If Debian starts forcing this stupid crap, I'm switching to KDE. -- E-gards: Jimmy ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Improving FiF
Am 11.10.2013 20:08, schrieb Dimitar Zhekov: Proposition: Remove the combo box. Add a paste icon on the right of files, above the Directory selection icon, and set it's tooltip to Paste the project patterns, if any. This is not the same functionality, choosing project on the combo is a sticky choice that follows the project settings, with this change the user would have to remember to paste when changing the project setting or after a custom search. And it also blocks editing the patterns. The most common starting point for specifying custom patterns does not work. It does, although a bit awkward: Choose project first, then custom. The project patterns remain and become editable. The same functionality can be achieved by using a check box, since the distinction between all and custom is nonsense. That'll still block editing, but at least won't be so clumsy. Or we can check if the field contains the current project patterns, and fill it with the new project patters on switch. Big deal. I dont feel strong about FiF, so do whatever you feel right. However I find the current combo box not that bad. The Project option is useful to automatically fill apply the project patterns. I do like your proposal of a Paste project patterns as well, but I fear that I need to press that repeatedly while now I can select project once and forget about it (even across restarts). Best regards. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Interested making a patch to add QML support
Ok, I've been testing with several of my QML files, and I think I've worked out most of the bugs, I am going to start working on my other project to test out the QML support, because as of my latest commit I can't find anymore bugs. I'm also open to anyone who wants to test it out to try to find bugs. Also, I joined the CTags dev mailing list, but it doesn't really seem to be active, is that project really even alive anymore? It looks like there hasn't been an update for quite a few years now, so I'm not sure I'll even be able to submit my code to them. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Improving FiF
Am 10.10.2013 03:43, schrieb Matthew Brush: On 13-10-09 01:01 PM, Dimitar Zhekov wrote: Hi, all, I want to discuss how our FiF works, why, and possible improvements. 1. The FiF dialog is created programatically. Is there any reason for that, or simply nobody cared to XML-ize it? I'm not aware of anything that can be done gtk+ calls, but can't be done by loading a XML and less gtk+ calls. Proposition: move the presentation to glade as much as possible, and fill the content with code, as in any normal program. I have done this before in a branch, but just the Glade part, which AFAIK is basically unmergable now because of volatility of Glade XML file. What I did was I made one single Search dialog in Glade that always showed the widgets that are in common between the various search dialogs (find, replace, fif), and then the specific options for the search type were each in their own container widget so they could be hidden/shown depending on which search dialog needs to be shown. There's some extra code to setup the dialog to be shown/work for the correct search type but it probably dwarfs the amount of code removed by putting all of them in the Glade file into a single DRY dialog. I agree with the idea of moving it into glade files where it's more easily hackable. Try my patched glate from [1]. It should solve the volatile XML output. Best regards. ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Improving FiF
Am 11.10.2013 21:30, schrieb Thomas Martitz: I agree with the idea of moving it into glade files where it's more easily hackable. Try my patched glate from [1]. It should solve the volatile XML output. [1]: https://github.com/kugel-/glade/tree/glade-3-8-fixes :) ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] Improving FiF
[...] custom - this is exactly the same as entering something in Files. Well, its Not Project, ie you need some way to switch away from using project settings, how good Custom is as a name is open. So it only exists because Project exists, and has no intrinsic value. The key point of the project option is that the file patterns are stored in the *project* file not in the *user* preferences. The project patterns are edited in the project preferences and the changed value appears in the FIF dialog field. This is consistent with all the other places project settings override user settings, they need to be edited in the project prefs so the user understands that they are saved in the project file. I'm not sure this is such a brilliant general UI decision, but its an attempt to ensure that users are not confused by the complex idea that one set of settings can override another, and that they know which set they are editing. I don't think this setting should deviate from the norm. project - this is not exactly the same as placing the Project 'File patterns' in Files. It pastes them, all right, but then locks the field, so you can't add / remove / edit a pattern. And the only reason to lock them is consistency: the 'project' choice must correspond to these patterns exactly. Well, if you do a Find, and then switch to 'custom', and then open the Files history, you will be able to edit the patterns after all... Last and least, 'project' grays the patterns, making them less visible. Make sure this functionality isn't important to the project plugin(s). I remember vaguely some significant discussion on the subject during one of the project plugin developments. If a plugin can access the field, it can simply fill it with something and lock it, without using an additional combo box. Its not just the project plugins, the built-in project does it too, see above. Of course, if I change FiF, I will make sure that the plugins work. The fact that you can edit the paths when you have switched to custom is irrelevant, that doesn't save to the project. I could not understand this sentence, but agree about not saving the project. It doesn't save all and custom either. :) Hopefully explained better above, sorry. Note that the combo box value and the custom/non-project/whatever we want to call them file patterns are meant to be saved in the user preferences, and it works for me. Proposition: Remove the combo box. Add a paste icon on the right of files, above the Directory selection icon, and set it's tooltip to Paste the project patterns, if any. This is not the same functionality, choosing project on the combo is a sticky choice that follows the project settings, with this change the user would have to remember to paste when changing the project setting or after a custom search. And it also blocks editing the patterns. The most common starting point for specifying custom patterns does not work. Explained (hopefully) above. The same functionality can be achieved by using a check box, since the distinction between all and custom is nonsense. That'll still block editing, but at least won't be so clumsy. I wasn't meaning to argue *for* a combo, just the distinction between project and custom/non-project/whatever. As we agreed, all is redundant if the delete is available, so a project check box is fine by me so long as it does the same as the project setting on the combo. Or we can check if the field contains the current project patterns, and fill it with the new project patters on switch. Big deal. If project is selected copy whatever the project has in it. Blank means everything so it too has to be copied. There is really no need to check if its the same, just copy it :) FiF checks if a project is open, but not whether it really contains 'File patterns' - RFC. Which is the project's problem, not the search's. Search should not impose requirements on projects. It doesn't, and I do not propose such a thing. It's just strange that project is disabled if there is no project, but enabled if there are no project paths. See above, no patterns means everything. [...] We are not using POSIX grep, it doesn't even support recursive search AFAIK. We are using GNU grep, and the above options work on our supported platforms, *NIX and Win32. I understood that in the past there was an attempt to not limit this to GNU Grep. Personally I would agree that it isn't worth supporting anything else, but Colomban needs to approve that decision and the documentation needs to be updated to note the limitation, and I guess the label on preferences-tools-grep should be GNU grep to make sure its understood thats all that is supported. The hard coded grep options thing has always been a problem (eg see the Note in the manual). The grep setting in tools should accept a whole command like
Re: [Geany-Devel] Interested making a patch to add QML support
On 12 October 2013 06:14, Tory Gaurnier tory.gaurn...@linuxmail.org wrote: Ok, I've been testing with several of my QML files, and I think I've worked out most of the bugs, I am going to start working on my other project to test out the QML support, because as of my latest commit I can't find anymore bugs. I'm also open to anyone who wants to test it out to try to find bugs. Also, I joined the CTags dev mailing list, but it doesn't really seem to be active, is that project really even alive anymore? It looks like there hasn't been an update for quite a few years now, so I'm not sure I'll even be able to submit my code to them. Colomban can confirm, but I don't think his last attempt to push stuff upstream has been accepted. Cheers Lex __**_ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-**bin/mailman/listinfo/develhttps://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] splitwindow2
On 11 October 2013 21:29, Colomban Wendling lists@herbesfolles.orgwrote: Le 10/10/2013 12:03, Thomas Martitz a écrit : Hello, I just wanted to let you know that I'm working on a new splitwindow implementation and I would like to have early input. [...] I don't have time yet to fully get down to the complicated discussion this went on, but I just wanted to point out I did a little refactoring of the splitwindow plugin some time ago, see https://github.com/b4n/geany/tree/splitwindow-refactoring-m The UI isn't nice and it's why I didn't merge it yet, but it makes the split view effectively useable. In practice, what it does is very simple: make sure whatever view you're touching it's actually always the primary Geany one, so it removes any need problem coming from Geany hardcoding some stuff. I can confirm I tried this and it worked, but I stopped using it. I hope I notified Colomban what the problem was, because I can't remember :-) But anyway it should be considered as a short term replacement of the plugin. Cheers Lex Regards, Colomban ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Re: [Geany-Devel] splitwindow2
[...] You don't need to walk any tree's, if you need to notebook from the scintilla, just store a pointer to the notebook in the scintilla, ex. using g_object_set_data() or more painfully by subclassing it. That pointer needs to be updated properly when the doc is moved. I rather save that and walk the tree, it's cheap enough. (g_object_get_data() is a hash-table lookup which isn't exactly free either) A few pointer compares up the tree is likely to be cheaper than the hash and has the advantage that sneaky plugins that move the widgets can't forget to update the pointer, so I'd say leave it as is. [...] There is no notebooks_arr in the current code. Instead there is a macro which makes it easy to transition to such an array later on. Seriously, if foreach_* macros are so frowned upon, why is Geany still full of them? I'm literally just following existing Geany-style with that macro. I personally like these macros, they are easy to understand and nicely short. I've also seen them used in other projects. I don't like any macros, and I suspect that the use of them is one of the things on Matthews list :) But leave it there for now, it will have to be up to the maintainer to decide when its committed, either way won't take much to change. [...] Yep, that's why my previous message, I'll try not to interfere here too much since no one is interested in the type of stuff I'm talking about probably (cleanup up the code en masse). I would still love to collaborate with you and other devs, even if I'm not going to make the uncertain (for me, anyway) big cleanup personally. Split window functionality should not depend on the big cleanup. Matthew may have a point that it might be easier after the cleanup, but so far its simple enough. Just keep going :) [...] On the plugin API, its gonna break, plugins will have to know about two notebooks, so at least some new functions are needed. But if you keep to your current arrangement of making the new functions a new name (even if its adding 2 to the end :) whilst keeping the old function, and you are careful about always adding to the end of structures, it may get away without an ABI break. That would be good because it means that old plugins will not break (clearly they won't use any of the new functionality which may hinder their usefullness, but they should not break). Currently there is a situation where some distros have a version of Geany that does not match the versions of geany-plugins they have, and it would be good to avoid that meaning that users can't use any plugins at all. Cheers Lex Best regards. __**_ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-**bin/mailman/listinfo/develhttps://lists.geany.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel
