Re: Using the same model in two treeview and prevent selecting the same item?
On Wed, Aug 24, 2011 at 03:50:46PM +0200, Michal Suchanek wrote: I have a list which I want to display in two treeviews and prevent selecting the same item in both. The idea is that the user selects an item in the first list, then the second list is shown, and it should not contain the item selected in the first list (or the item should be inactive or whatever). I tried using a model filter to this end. It has an option to set custom filter callback and in this callback I fetch the selection of the first list (if any) and return false if the filtered item is the same as selected. I would just render the item as inactive using cell renderer's sensitive property and prevent it from being selected using gtk_tree_selection_set_select_function(). You need to remember the current selection but otherwise it is pretty cheap: if the selected row changes only two rows have to receive row-changed to update the other treeview: the previously selected one (becomes selectable) and the newly selected one (becomes unselectable). Also, depending on the application this might be visually preferrable to appearing and disappearing rows. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtksourceview-2.0 with custom paths
Hi Allin, gtksourceview by default uses the XDG base directory specification to lookup .lang files and style schemes, so it should just work without having to manually force the search path with gtk_source_language_manager_set_search_path. For instance gedit is ported to both windows and osx and the path of lang files does not have any special treatment as far as I recall. The important thing (at least for windows) is that your package follows the right conventions in the name of directories _relatively_ to your binary, for instance gedit's installer has: install dir bin gedit.exe share gtksourceview-2.0 language-specs c.lang ... Ciao Paolo Il giorno lun, 22/08/2011 alle 20.00 -0400, Allin Cottrell ha scritto: First off, sorry if this is the wrong place to ask. I see from http://projects.gnome.org/gtksourceview//development.html that the recommendation is to ask about gtksourceview on gnome-devtools, but that list appears to be pretty much moribund so I'm trying here. I work on a cross-platform GTK app, and I'm trying to get gtksourceview-2.0 working in the context of packages for Windows and OS X, where I don't know the final installation path and so I need to specify the search paths for language-specs and style files at runtime. Right now I'm emulating this situation on Linux, and while I seem to be close to success, no cigar yet. Any help would be appreciated. (BTW, my testing is with version 2.10.5, which I take to be latest stable in the 2.0 series, but should I be using 2.11.N?) Step 1: Specify a non-standard location for the lang files. Before displaying any text I grab the default languages manager with gtk_source_language_manager_get_default() and set a custom location using gtk_source_language_manager_set_search_path Result: Success. I get syntax highlighting OK, even if I hide the standard language-specs directory. Step 2: Specify a non-standard location for the style files. Again, before displaying anything I grab the default style scheme manager with gtk_source_style_scheme_manager_get_default() and set a custom directory using gtk_source_style_scheme_manager_set_search_path() gtk_source_style_scheme_manager_force_rescan() (I'm not sure the latter call is necessary, but I threw it in for good measure.) Result: Failure: no syntax highlighting. Though I don't need styles other than classic, I've tried this with the custom directory containing the entire contents of the standard styles directory. I guess I must be missing something. By inserting print statements I can see that after Step 2, gtk_source_style_scheme_manager_get_scheme_ids() is giving an apparently valid list of ids, corresponding to the style xml files in the non-standard location (which in some experiments was a subset of the full list, but including classic). One more observation: In each case my setting of the non-standard location was an array of just two *gchars, the custom path followed by NULL. In the style-scheme-manager case (only), the result (syntax highlighting or none) was conditional on whether or not the standard styles directory was visible or hidden (renamed) at runtime. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtksourceview-2.0 with custom paths
On Wed, 24 Aug 2011, Paolo Borelli wrote: gtksourceview by default uses the XDG base directory specification to lookup .lang files and style schemes, so it should just work without having to manually force the search path with gtk_source_language_manager_set_search_path. For instance gedit is ported to both windows and osx and the path of lang files does not have any special treatment as far as I recall. The important thing (at least for windows) is that your package follows the right conventions in the name of directories _relatively_ to your binary, for instance gedit's installer has: install dir bin gedit.exe share gtksourceview-2.0 language-specs c.lang ... OK, thanks, I'll try that. For the record, I found that the procedure I was trying (below) works if I use gtk_source_style_scheme_manager_set_search_path() to set the style path _before_ the first call to gtk_source_buffer_new() but not after. Allin Cottrell Il giorno lun, 22/08/2011 alle 20.00 -0400, Allin Cottrell ha scritto: First off, sorry if this is the wrong place to ask. I see from http://projects.gnome.org/gtksourceview//development.html that the recommendation is to ask about gtksourceview on gnome-devtools, but that list appears to be pretty much moribund so I'm trying here. I work on a cross-platform GTK app, and I'm trying to get gtksourceview-2.0 working in the context of packages for Windows and OS X, where I don't know the final installation path and so I need to specify the search paths for language-specs and style files at runtime. Right now I'm emulating this situation on Linux, and while I seem to be close to success, no cigar yet. Any help would be appreciated. (BTW, my testing is with version 2.10.5, which I take to be latest stable in the 2.0 series, but should I be using 2.11.N?) Step 1: Specify a non-standard location for the lang files. Before displaying any text I grab the default languages manager with gtk_source_language_manager_get_default() and set a custom location using gtk_source_language_manager_set_search_path Result: Success. I get syntax highlighting OK, even if I hide the standard language-specs directory. Step 2: Specify a non-standard location for the style files. Again, before displaying anything I grab the default style scheme manager with gtk_source_style_scheme_manager_get_default() and set a custom directory using gtk_source_style_scheme_manager_set_search_path() gtk_source_style_scheme_manager_force_rescan() (I'm not sure the latter call is necessary, but I threw it in for good measure.) Result: Failure: no syntax highlighting. Though I don't need styles other than classic, I've tried this with the custom directory containing the entire contents of the standard styles directory. I guess I must be missing something. By inserting print statements I can see that after Step 2, gtk_source_style_scheme_manager_get_scheme_ids() is giving an apparently valid list of ids, corresponding to the style xml files in the non-standard location (which in some experiments was a subset of the full list, but including classic). One more observation: In each case my setting of the non-standard location was an array of just two *gchars, the custom path followed by NULL. In the style-scheme-manager case (only), the result (syntax highlighting or none) was conditional on whether or not the standard styles directory was visible or hidden (renamed) at runtime. -- Allin Cottrell Department of Economics Wake Forest University ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list