Re: Setting the scroll position of a GtkTextView in GtkScrolledWindow after render
On Mon, 2019-04-08 at 13:07 +, Andri Möll via gtk-app-devel-list wrote: > I can't figure out if it's me or something's amiss. I'm trying to > set > the scroll position after rendering a GtkTextView May that be still this old bug: https://picheta.me/articles/2013/08/gtk-plus--a-method-to-guarantee-scr olling.html I think in 2015 I was concerned with that bug, and I asked here, no response. So I had to apply the old fix mentioned in above link for my Nim editor. Development of GtkSourceView is not very active, so that bug may still exist. And in case you have not noticed yet, the gtk-list has basically moved to discourse forum. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reduce the size of a GtkScale indicator
On Fri, 2018-03-30 at 22:25 +0200, Stefan Salewski wrote:
> You may even name your widgets and then can set
> CSS properties of single widgets.
Like this:
import gintro/[gtk, glib, gobject, gio]
proc appActivate(app: Application) =
let window = newApplicationWindow(app)
let scale = newScaleWithRange(Orientation.horizontal, 0.0, 100.0, 10.0)
scale.setName("MyTinyOne")
echo scale.getName
let cssProvider = newCssProvider()
let data = "scale#MyTinyOne slider {min-width: 4px; min-height: 4px; margin:
0px}"
discard cssProvider.loadFromData(data)
let styleContext = scale.getStyleContext
assert styleContext != nil
addProvider(styleContext, cssProvider, STYLE_PROVIDER_PRIORITY_USER)
window.add(scale)
showAll(window)
proc main =
let app = newApplication("org.gtk.example")
connect(app, "activate", appActivate)
discard run(app)
main()
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reduce the size of a GtkScale indicator
On Fri, 2018-03-30 at 21:01 +0200, Stefan Salewski wrote:
> I have the impression there is no CSS property to make GtkScale
> slider
> smaller.
Finally I have a working solution. The trick is, that we have to set
margin also. Margin is negative in default, which does not work with
tiny min-width and max-width. margin is the size of the colored bar.
Here is the Nim code for a tiny slider, code for other languages should
be similar:
import gintro/[gtk, glib, gobject, gio]
proc appActivate(app: Application) =
let window = newApplicationWindow(app)
let scale = newScaleWithRange(Orientation.horizontal, 0.0, 100.0, 10.0)
let cssProvider = newCssProvider()
let data = "scale slider {min-width: 4px; min-height: 4px; margin: 0px}"
discard cssProvider.loadFromData(data)
let styleContext = scale.getStyleContext
assert styleContext != nil
addProvider(styleContext, cssProvider, STYLE_PROVIDER_PRIORITY_USER)
window.add(scale)
showAll(window)
proc main =
let app = newApplication("org.gtk.example")
connect(app, "activate", appActivate)
discard run(app)
main()
Note that this CSS code does affect only the widgets of your tool, not
other Gnome widgets. You may even name your widgets and then can set
CSS properties of single widgets.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reduce the size of a GtkScale indicator
On Thu, 2018-03-29 at 21:50 +0200, Bas Wassink wrote: > I kinda figured I had to go the CSS route, I have the impression there is no CSS property to make GtkScale slider smaller. I did a few tests yesterday, without a result. But I have to admit that for my screen it is already small. Maybe Mr Bassi will have an idea when he is back from vacation. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Reduce the size of a GtkScale indicator
On Thu, 2018-03-29 at 18:02 +0200, Bas Wassink wrote:
> Any hints?
https://developer.gnome.org/gtk3/stable/chap-css-overview.html
grep -A100 GtkScale ~/.config/gtk-3.0/gtk-default.css
Well, I do provide a colored label example at
https://github.com/StefanSalewski/gintro
Starting from that one, it is easy to get a really big slider:
import gintro/[gtk, glib, gobject, gio]
proc appActivate(app: Application) =
let window = newApplicationWindow(app)
let scale = newScaleWithRange(Orientation.horizontal, 0.0, 100.0, 10.0)
let cssProvider = newCssProvider()
let data = "scale slider {min-width: 32pt; min-height: 32pt;}"
discard cssProvider.loadFromData(data)
let styleContext = scale.getStyleContext
assert styleContext != nil
addProvider(styleContext, cssProvider, STYLE_PROVIDER_PRIORITY_USER)
window.add(scale)
showAll(window)
proc main =
let app = newApplication("org.gtk.example")
connect(app, "activate", appActivate)
discard run(app)
main()
Yes, I know you want a tiny one. But setting nim-width, min-height to
small values does not decrease size, which is not really surprising, as
that are min and max values. So we have to search for other properties
-- maybe Mr Bassi or Mr Bader will tell us.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: background color for GtkTreeView
On Sat, 2018-03-10 at 14:26 +0100, codemusi...@gmail.com wrote:
> Hi there,
>
> I'm trying to change the background-color of a GtkTreeView by adding
> a
> css provider with the following style set:
>
> treeview { background-color: #fffae1; }
>
> Unfortunately this has the effect that the row selection color
> changes
> from the default blue to this particular background color as well.
>
> Note that I'm aware that I can change the background color of
> individual rows. However, I want to change the color of the entire
> widget including the whitespace.
>
> I can't figure out how to prevent the row selection color from
> changing
> as well.
>
> Any help would be greatly appreciated.
>
>
GTK3?
grep -C3 "treeview.view.selected" .config/gtk-3.0/gtk-default.css
-GtkTreeView-tree-line-width: 1;
-GtkTreeView-tree-line-pattern: '';
-GtkTreeView-expander-size: 16; }
treeview.view:selected:focus, treeview.view:selected {
border-radius: 0; }
treeview.view:selected:backdrop, treeview.view:selected {
border-left-color: #a5c8ec;
border-top-color: rgba(46, 52, 54, 0.1); }
treeview.view:disabled {
--
textview text selection:focus,
textview text selection, flowbox flowboxchild:selected,
spinbutton:not(.vertical) selection,
entry selection, modelbutton.flat:selected,
.menuitem.button.flat:selected, treeview.view:selected:focus,
treeview.view:selected, row:selected, calendar:selected {
background-color: #4a90d9; }
row:selected label, label:selected, .selection-mode
button.titlebutton, .view:selected:focus, iconview:selected:focus,
.view:selected, iconview:selected,
.view text:selected:focus,
--
I assume that after changing complete background, you have to set
background for selected again. Above #4a90d9 looks like that color. You
have to find out how to do it exactly yourself.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: centered and right justified label in the same line.
On Mon, 2018-02-26 at 09:16 +0100, Wojciech Puchar wrote: > How to do this in GTK 2. whatever i try i'm getting first label > centered > relative to space remaining after second label not to whole hbox. how > to > do this properly? > > That may be not that easy. Maybe try a hbox, which again contains 3 hboxes. 3 because so it may allow center the middle one. Then put your labels into some of these 3 boxes. Or you may try a table or grid with 3 columns. I think grid exists only for GTK3. Maybe someone other has a better solution. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: hints when keeping mouse cursor over widget
On Fri, 2018-02-23 at 14:17 +0100, Wojciech Puchar wrote: > Gimp can do this so GTK can do this but i cannot find how. > > > How to turn off text hints (help) when mouse pointer hovers over the > widget? > See https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-tooltip-text and https://developer.gnome.org/gtk3/stable/GtkTooltip.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkdialog maximum size
On Wed, 2017-09-13 at 10:34 +, Rúben Rodrigues wrote: > Why are you saying that using a scrolled window with parts invisible > is > not user frindly? Because the user has to scroll :-) Of course having a scrolled window with active scrollbars can be necessary -- when there is really more content as fits on the screen. But it may be more user friendly to make widgets or text not too large, or to hide rarely used widgets. So all fits onto the screen. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtkdialog maximum size
On Wed, 2017-09-13 at 10:59 +0100, Emmanuele Bassi wrote: > Why are you using a GtkDialog? You should be using a GtkWindow for a > complex UI. > > Additionally, the size of a top-level is given by its contents, > unless > you specify a size yourself. If your UI is too big, you'll have to > arrange it differently. For a plain Window he may use of course a GtkScrolledWindow. I am not sure if that would work for a dialog too, but I think so. But of course a scrolled window with parts invisible is not really user friendly... Ruben, what do you expect when contents do not fit onto screen? And have you solved your other problem with the two dialogs following each other? I have seen a long reply of somebody to your question -- did that helped you? Next question may be how to detect that content is too large for screen, and how to shrink content. Maybe check allocation for window first. And when larger than screen, maybe reduce text size, widget size or hide some widgets. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Show dialog after hide another
On Fri, 2017-09-08 at 11:11 +, Rúben Rodrigues wrote: > Please!! > > Help.. Well, I guess what you want is displaying a message dialog without prior user actions. Maybe you can emit a signal to do that? I don't know, have never needed that. Maybe you can just modify your first dialog, display another text? Or, maybe what you really want is something like the GtkAssistant, I think that one is something that guides a user through a longer sequence of actions. Finally, you misses to tell us if you are using mainline GTK3 or a different version, which OS, and what your great FOSS application on which you are working is. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Multi page widgets in Gtk
On Sun, 2017-09-03 at 13:42 +0100, Mike Martin wrote: > For one of my apps I want to setup a multi page widget with next > previous > navigation. Have you tried https://developer.gnome.org/gtk3/stable/GtkAssistant.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Preferred height/width error message
On Sun, 2017-07-23 at 17:46 +0100, Mike Martin wrote: > Gtk version 3.22 I see a similar message for evince pdf viewer whenever I use it since some months. But I have no idea for the reason unfortunately (evince:5623): Gtk-WARNING **: Allocating size to EvSidebar 0x12dd6c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Close button in GtkNotebook
On Sun, 2017-05-28 at 16:08 -0300, Augusto Fraga Giachero wrote: > I've been playing with Glade and GtkNotebook for while, and I > couldn't > figure a way to enable the close button on the tabs I guess what you want is what gedit does with the tabs? The gedit code has been modified a few times in the last years, I am currently using code from GTK 3.20 in my Nim editor. See # from 3.20 gedit-documents-panel.c ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
On Thu, 2017-03-30 at 10:21 +0100, Emmanuele Bassi wrote: > g_idle_add() or, better yet, g_main_context_invoke(). Thanks. While I can remember have read your explanations somewhere already, I really missed that g_main_context_invoke() function. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
On Thu, 2017-03-30 at 11:10 +0200, Nicola Fontana wrote:
>
>
> As said you can leverage the main loop and unroll yours, e.g.:
>
> gboolean my_idle_callback()
> {
> gint n;
> for (n = 0; n < 100; ++n) {
> ...
> }
> return FALSE;
> }
>
> should become:
>
> gboolean my_unrolled_idle_callback()
> {
> static gint n = 0;
> ...
> ++n;
> return n < 100;
> }
>
> Depending on your use case, the above could or could not be
> possible.
>
Ah yes, that is an interesting idea.
> >
> > So I have to go back to my initial idea -- create a thread which
> > gets a
> > message for each "changed" signal, and then calls an idle function
> > only
> > for the last message in the queue each. I have to use
> > gdk_threads_add_idle() then.
>
> This is probably the cleanest solution, although I don't
> understand why you would have to use gdk_threads_add_idle().
I think gdk_threads_add_idle() is the recommended way to update the GTK
GUI from inside a second thread. I am doing it in the current version
of the editor already for querying and displaying extended symbol
information, see https://github.com/ngtk3/NEd
Here is where gdk_threads_add_idle() was suggested:
https://developer.gnome.org/gdk3/stable/gdk3-Threads.html
"You can schedule work in the main thread safely from other threads by
using gdk_threads_add_idle() and gdk_threads_add_timeout()"
>
> >
> > The task of that idle function in my current use case would be to
> > get
> > highlight syntax information from the IDE process called nimsuggest
> > and
> > then to apply the corresponding tags to gtksource textbuffer.
>
> IMO it is essential to split your code in two parts: (1) gathering
> the highlight information and (2) applying it to the textbuffer.
Yes, that was my thoughts too. It would imply some additional code, but
may be the best solution.
>
> (1) can be run entirely in the working thread (hence non-blocking)
> while (2) must be implemented as a callback to be run in the GTK+
> thread. I cannot believe (2) takes tenths of second.
>
> When you are ready from (1) you can spawn the idle callback with
> g_source_attach()... no needs for gdk_threads_add_idle(). In the
> following StackOverflow answer I provided an example in C:
>
> http://stackoverflow.com/questions/27950493/safety-of-using-pthreads-
> in-gtk2-0-application#27990662
>
Thanks for that suggestion, I will look at the stackoverflow example.
And indeed, applying the text tags to the gtksource buffer is finally
the only critical part. I dont know how fast that really is, I would
assume that it takes less than 50 ms, what would be fine. If it really
is slow, I may split it in multiple parts/calls.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
On Thu, 2017-03-30 at 09:38 +0200, Stefan Salewski wrote: > Currently I wonder if the call of gtk3.mainIteration() inside the > idle > function is possible and if it would help updating the display. In my > first draft of the Nim toy chess I used something like this > > while gtk3.eventsPending(): discard gtk3.mainIteration() Yes, that has an effect, it seems to allow GUI redraw, but keyboard input remains sluggish. If I add additional a sleep() function call keyboard seems to react better. But of course that is no real solution, so I have to test the thread idea next. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
On Wed, 2017-03-29 at 23:26 +0200, Nicola Fontana wrote: > > > idle functions do *not* run in the background so if you don't > release the CPU you will experience what you described. > > AFAIK all the GMainLoop code is single-threaded hence, as a > consequence, you will block the UI whenever the CPU is busy > running your code, being it inside a signal handler, a timeout > function or (as in your case) an idle function. > > Just avoid loops when you know they are expensive. Instead > leverage the cyclic nature of GMainLoop for iterating over your > code, i.e. by respawning your idle function as much as needed. > In that case it is really a bad idea to have a outer loop in that idle function :-( So I have to go back to my initial idea -- create a thread which gets a message for each "changed" signal, and then calls an idle function only for the last message in the queue each. I have to use gdk_threads_add_idle() then. The task of that idle function in my current use case would be to get highlight syntax information from the IDE process called nimsuggest and then to apply the corresponding tags to gtksource textbuffer. Unfortunately that may take a few hundred milliseconds for each full update. Currently I wonder if the call of gtk3.mainIteration() inside the idle function is possible and if it would help updating the display. In my first draft of the Nim toy chess I used something like this while gtk3.eventsPending(): discard gtk3.mainIteration() to avoid display freeze. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
On Wed, 2017-03-29 at 16:47 +0200, Stefan Salewski wrote: > On Wed, 2017-03-29 at 09:42 +0200, Stefan Salewski wrote: > > > > It is still the old problem: > > Well, after some thinking I have the feeling that it may work with > only > an idle function, so no separate thread and message passing is > necessary: The callback set a flag indicating that there is work to > do, > and calls the idle function unless the idle function is still > working. > That idle functions has an outer loop, which tests the flag and > returns > if unset. Otherwise it clears the flag and does the work. Will test > soon... > Yes, basically that works fine. Problem is the idle function added with https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-idle-add I have the strong feeling, that the provided function is not running silently in the background, but it is just called at some point and then blocks user input until the function terminates. At least, when that function is added with g-idle-add on GtkTextBuffer changed signal and that functions does only a delay of 2000 ms, then for that time user input into text buffer is blocked. That was not what I expected. And it is bad, user input becomes a bit sluggish. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Input event reduction
On Wed, 2017-03-29 at 09:42 +0200, Stefan Salewski wrote: > It is still the old problem: Well, after some thinking I have the feeling that it may work with only an idle function, so no separate thread and message passing is necessary: The callback set a flag indicating that there is work to do, and calls the idle function unless the idle function is still working. That idle functions has an outer loop, which tests the flag and returns if unset. Otherwise it clears the flag and does the work. Will test soon... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: SpinButton size
On Mon, 2017-03-27 at 14:23 +, Rúben Rodrigues wrote:
> hi guysm
>
> it's possible to change size of spinbuttons? In touchscreen mode
> spinbutton are still small.. We can change it's size with css
> provider?
>
>
That may be possible...
I found some example code in gedit C sources for changing widget sizes,
that code has changed from GTK version to GTK version. For 3.20 I have
working code like:
# from 3.20 gedit-documents-panel.c
let closeButton = button(newObject(typeButton, "relief", ReliefStyle.NONE,
"focus-on-click", false, nil))
let context = closeButton.getStyleContext
context.addClass("flat")
context.addClass("small-button")
let icon = newThemedIconWithDefaultFallbacks("window-close-symbolic")
let image: Image = newImage(icon, IconSize.MENU)
objectUnref(icon)
closeButton.add(image)
discard gSignalConnect(closeButton, "clicked", gCallback(closeTab), scrolled)
Well, that is not for spin button, but ordinary button. And again you
did not said if you want a solution for GTK2 or GTK4 on macosx.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Input event reduction
Well, I think I have asked this already some years ago at gtk-list. (And I spent some hours experimenting with stuff like event_pending() and such, without success.) It is still the old problem: We have input events, for example keystrokes, and a function that can only process a few events per second. What we want: If there are more than one event of this type pending (in the queue) than discard all but the last one. That seems to be really hard in GTK3. One solution, which is used in the NEd Nim editor: Create a separate task, send the events though a channel to that task. That channel behaves like a queue, so the task can discard events easily and process always only the last one. Problem is, that GTK is not thread safe, so that task can not do GUI update itself, but has to use an Idle_Add function. All that works fine, but that is more than 10 lines of code for such a trivial problem. Currently I get the "changed" signal of a GTk Text Buffer -- when the user types fast, there may be up to ten function calls per second initiated. Processing these realtime is still possible on a fast CPU, but to save resources (battery power for example) it would be better to drop a few events when there are many, but always process the last one. (Task here is smart syntax check or syntax highlight, so the last input is always what matters most.) Timer events would be an option, but that would imply a permanent delay. What we want instead is immediate reaction when there are input events. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Re-drawing GtkDrawingArea surface on motion-notify-event
On Sun, 2017-03-19 at 22:12 +, Marcin Kolny wrote: > I'd like to write very simple application for drawing lines. You can restrict all drawing operations to a rectangle enclosing your line. For each move with button pressed, fill that rectangle with background color and then draw the line with foreground color. Or, you may save the old line start and end points and paint that old line with background color before drawing the new line. I think there is not much benefit for using an temporary surface for this use case. For more complicated graphics it can become a bit slow indeed -- I once tried it for my schematics editor -- there I used a bounding box for all the graphical elements, when one element is moved, I had to draw its background and then all other elements overlapping with that background element. Using OpenGl may be faster and easier, because you can fast just redraw all. I think GTK3 now has a gl-area widget. The problem with Gl is that it is basically more for drawing triangles than for drawing lines... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to change GTK+3 label color dynamically
On Thu, 2017-03-16 at 09:55 +, Rúben Rodrigues wrote: > Hi, > > THanks. This is dynamically? I need in c language if possible :S > > Thanks Yes. The example https://github.com/ngtk3/nim-gtk3/blob/master/test/colors.nim is dynamically, I used it to generate some color schemes. Entered color hex value in a text entry widget, and that color was applied. As I said, it was working for 3.18. I think for 3.20 and above some CSS names have changed, I had not the time to really investigate that. I have no C code currently, I think my Nim code was inspired by Python code, but I have no link to that python code currently. For C it is the same pattern -- generate a CSS string and apply it. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to change GTK+3 label color dynamically
On Wed, 2017-03-15 at 15:11 +, Rúben Rodrigues wrote: > Hi, > > Now i need to change GtkLabel color dinamically, so i thing that i > can't > use Css to do this.. I do this in Gtk2: > > gtk_widget_modify_fg(GTK_WIDGET(gtk_builder_get_object(builder,"label > ")),GTK_STATE_NORMAL, > ); > > How can i change the color in Gtk3? > > You can do it with CSS. But it has changed a bit for 3.20. You may compare this thread: https://mail.gnome.org/archives/gtk-list/2016-November/msg6.html Well, that was not for label widget, but for tooltip. But label widget should behave similar. And with similar code I once set foreground and background for button widgets -- I had that working for 3.18, but I have not yet fixed that for 3.20. (https://github.com/ngtk3/nim-gtk3/bl ob/master/test/colors.nim) ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Homogeneous table
On Fri, 2017-03-10 at 10:32 +, Rúben Rodrigues wrote: > HI, > > Thanks for your reply. NExt i will change to gtk3, but i think that i > need to change many things.. It could be simple to make a homogeneous > table and hide images, unfortunately not.. I don't know exactly what you desire, but I have the feeling that it may be possible. Maybe you can use dummy images as place holders? Or maybe you can put your images first in some sort of (fixed size) container, and than put that container into the table? Or, when I remember the old Krause book correctly, I think there is some type of container available in GTK2 with allows absolute positioning. Maybe use that instead of a table? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ progress bar color
On Wed, 2017-03-08 at 15:23 +, Emmanuele Bassi wrote: > Sorry, we haven't yet found the way to write a `gtk_do_what_i_mean()` > function. > > > But we have to tell them: We should not > > do that, it may be possible with CSS... So we have no Kids in GTK > for > > more than 10 years now, so so new coders, only a few tired seniors > > left. > > Again, I have no idea what kind of "kids in GTK" you are referring > to. > I see a lot of newcomers approaching GTK and GNOME development, > though. > > You may be hanging around in the wrong places. > > Ciao, > Emmanuele. Yes maybe. I am subscribbed to gtk-list, gtk-app-devel, gtk-source-view and gedit list. The last two are absolutely death. Someone told me to try IRC, so I joined it some months ago for a few hours, there was no traffic at all, so I disconnected... Other places? Years ago there was a web forum without much traffic, I am not sure if that still exists. Well I have never looked on Facebook or youtube for GTK people :-) People generally start in age about 12 with programming, and they like to do something that is fun. 5 lines CSS code to change a color is not that much fun unfortunately. Do you think they come back to GTK when they have threir PhD? At least, the few GTK coders I am aware of are all 30 or more years old, most are even older. Currently I am working on high level gobject introspection Nim bindigs, as you may remember... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ progress bar color
On Wed, 2017-03-08 at 15:00 +, Rúben Rodrigues wrote: > Thanks for your help... Yes i don't understand why gtk doesn't aloow > us > to do some "basic" things.. Well, the GTK senior developers will say that such "color hacks" are ugly and do not fit theming well. That may be true. But the Problem is: When we try to teach Kids GTK programming, one of their first question is: How can I change that color. They expect a simple function and would have fun playing with it. But we have to tell them: We should not do that, it may be possible with CSS... So we have no Kids in GTK for more than 10 years now, so so new coders, only a few tired seniors left. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ progress bar color
On Wed, 2017-03-08 at 15:52 +0100, Stefan Salewski wrote:
> On Wed, 2017-03-08 at 14:18 +, Rúben Rodrigues wrote:
> >
> > I asked to the Google before, but he don't give me nothing about
> > this
> > :-). PRELIGHT doesn't work too..
>
>
Well, the fix suggested by Owen Taylor in that old thread solved it for
me:
#include
gint main(gint argc,gchar *argv[])
{
GtkWidget *window;
GtkWidget* bar;
GdkColor color;
GtkStyle *style;
gtk_init (,);
window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
bar=gtk_progress_bar_new();
gdk_color_parse("red",);
gtk_widget_modify_bg(bar,GTK_STATE_NORMAL, );
gtk_widget_modify_bg(bar,GTK_STATE_PRELIGHT, );
gtk_widget_modify_bg(bar,GTK_STATE_ACTIVE, );
gtk_widget_modify_bg(bar,GTK_STATE_SELECTED, );
gtk_widget_modify_bg(bar,GTK_STATE_INSENSITIVE, );
gtk_widget_modify_fg(bar,GTK_STATE_NORMAL, );
gtk_widget_modify_fg(bar,GTK_STATE_PRELIGHT, );
gtk_widget_modify_fg(bar,GTK_STATE_ACTIVE, );
gtk_widget_modify_fg(bar,GTK_STATE_SELECTED, );
gtk_widget_modify_fg(bar,GTK_STATE_INSENSITIVE, );
style = gtk_style_new ();
gdk_color_parse ("red", >bg[GTK_STATE_PRELIGHT]);
gtk_widget_set_style (bar, style);
g_object_unref (style);
gtk_progress_bar_set_fraction(GTK_PROGRESS_BAR(bar),0.5);
gtk_container_add(GTK_CONTAINER(window),bar);
gtk_widget_show_all (window);
gtk_main();
return 0;
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ progress bar color
On Wed, 2017-03-08 at 14:18 +, Rúben Rodrigues wrote:
> I asked to the Google before, but he don't give me nothing about
> this
> :-). PRELIGHT doesn't work too..
Yes, you are right.
I just took this example:
https://www.spinics.net/lists/gtk/msg00686.html
//gcc -o simple t.c `pkg-config --libs --cflags gtk+-2.0`
#include
gint main(gint argc,gchar *argv[])
{
GtkWidget *window;
GtkWidget* bar;
GdkColor color;
gtk_init (,);
window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
bar=gtk_progress_bar_new();
gdk_color_parse("red",);
gtk_widget_modify_bg(bar,GTK_STATE_NORMAL, );
gtk_widget_modify_bg(bar,GTK_STATE_PRELIGHT, );
gtk_widget_modify_bg(bar,GTK_STATE_ACTIVE, );
gtk_widget_modify_bg(bar,GTK_STATE_SELECTED, );
gtk_widget_modify_bg(bar,GTK_STATE_INSENSITIVE, );
gtk_widget_modify_fg(bar,GTK_STATE_NORMAL, );
gtk_widget_modify_fg(bar,GTK_STATE_PRELIGHT, );
gtk_widget_modify_fg(bar,GTK_STATE_ACTIVE, );
gtk_widget_modify_fg(bar,GTK_STATE_SELECTED, );
gtk_widget_modify_fg(bar,GTK_STATE_INSENSITIVE, );
gtk_progress_bar_set_fraction(GTK_PROGRESS_BAR(bar),0.5);
gtk_container_add(GTK_CONTAINER(window),bar);
gtk_widget_show_all (window);
gtk_main();
return 0;
}
And on my box the bar is still blue!
GTK can be really hard and stubborn sometimes.
I do not have the GTK2 source codes on my box currently, so I can not
look at it currently. Maybe Mr Bassi or someone of the other few
remaining GTK insiders is still following this thread. At least now
your real goal is clear and we have tried it ourself :-)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ progress bar color
On Wed, 2017-03-08 at 13:30 +, Rúben Rodrigues wrote: > Yes, doesn't work for me.. Because: > > gtk_widget_modify_bg(GTK_WIDGET(gtk_builder_get_object(builder,"Menu_ > Birds_ProgressBr")),GTK_STATE_NORMAL, > ); > > This changed background color, and this > > > gtk_widget_modify_fg(GTK_WIDGET(gtk_builder_get_object(builder,"Menu_ > Birds_ProgressBar")),GTK_STATE_NORMAL, ); > > Change text color. I want to change bar color.. Well, than we have to ask Mr Bassi or Google :-) Or look at the code... http://stackoverflow.com/questions/11172804/pygobject-gtk-entry-changing-progress-bar-color So please try gtk.STATE_PRELIGHT. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ progress bar color
On Wed, 2017-03-08 at 12:29 +, Rúben Rodrigues wrote: > Hi, > > Thanks. Yes i want to change in gtk 2.x and change it in my app > only. > There's no way in proprieties? Do the ordinary GTK2 functions not work for your case? Like gtk_widget_modify_fg() and gtk_widget_modify_bg() https://developer.gnome.org/gtk2/stable/GtkWidget.html#gtk-widget-modify-fg http://stackoverflow.com/questions/99488/how-do-i-change-the-colors-of-an-arbitrary-widget-in-gtk ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Gtk+ progress bar color
On Tue, 2017-03-07 at 15:43 +, Rúben Rodrigues wrote: > > > > Hi guys, > > > > How can i change progress bar color? > > > > Thanks > > > > For GTK 3.20 and above you can do it, using CSS. I did a similar fix for scrollbar width for my 27 inch 4 display. I think I wrote how I did it here some months ago. Basically you grap the CSS file, search for progressbar, copy that section to ~/.config/gtk-3.0/gtk.css and modify the color entry with a text editor. When you restart your application you should notice the new color. But maybe you want to use GTK2, Windows or Mac, or change it only for a specific app? And of course generally it may be a bad idea to modify single colors, because it may not really fit for arbitrary themes. And, not all widgets have plain colors, some have gradients and more. But I think for progressbar there is indeed a single color defined for GTK 3.20. And for personal use it should be OK. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
They broke the CSS custom color settings in 3.20
You may know the Nim editor from
https://github.com/ngtk3/NEd
Getting tooltips with white background for a dark gtksourceview color
scheme was already one of the harder task for GTK 3.18 -- but somehow I
managed it. Recently I got GTK 3.20 and had to notice that setting
background for tooltip does not work any more. Setting the colors was
done this way for GTK 3.18:
const
str0 = ".tooltip {background-color: rgba($1, $2, $3, 0.9); color: rgba($4,
$5, $6, 1.0); \n}"
proc setTTColor(fg, bg: cstring) =
var rgba_bg: gdk3.RGBAObj
var rgba_fg: gdk3.RGBAObj
if not rgbaParse(rgba_fg, bg): return
if not rgbaParse(rgba_bg, fg): return
let str: string = str0 % map([rgba_bg.red, rgba_bg.green, rgba_bg.blue,
rgba_fg.red, rgba_fg.green, rgba_fg.blue], proc(x: cdouble): string =
$system.int(x*255))
var gerror: GError
let provider: CssProvider = newCssProvider()
let display: Display = displayGetDefault()
let screen: gdk3.Screen = getDefaultScreen(display)
styleContextAddProviderForScreen(screen, styleProvider(provider),
STYLE_PROVIDER_PRIORITY_APPLICATION.cuint)
discard loadFromData(provider, str, GSize(-1), gerror)
objectUnref(provider)
Even for a simple test application setting of background color seems
not to work any more:
https://github.com/ngtk3/nim-gtk3/blob/master/test/colors.nim
I have the feeling that fixing this basically simple problem will take
much time again. Have already done some (Google) investigations
yesterday, but found no good hints. GtkInstector seems to be not really
helpful for tooltips unfortunately. I think I can remember some
questions about CSS problems on this list in recent months, some maybe
with replies of Mr Bassi. Have to dig :-)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Getting focus
On Tue, 2016-08-23 at 00:38 +0200, rastersoft wrote: > It's not a problem of being early: I even tried to put a 1-second timer > to call to grab_focus(), but didn't work. > > In fact, the first time I create the window it works fine, but seems to > fail when I hide it and show it again. So it may be related to the window manager? Is it Linux with Gnome3 shell? Gnome 3.20? May other programs steal the focus? Do other tools work fine? When you hide and show gedit, will it have the focus? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Getting focus
On Sun, 2016-08-21 at 21:56 +0200, rastersoft wrote: > I tried to > call "grab_focus" on the "map" callback... but doesn't work. The map signal may be too early. Maybe g_signal_connect_after() may work. After map signal map_event is emmited, maybe you can use that one. Or try the draw signal, I guess it should be emmited after map signal. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: ‘gtk_widget_override_background_color’ is deprecated
On Thu, 2016-08-18 at 22:21 +0200, rastersoft wrote: > Hi all: > > Gtk.Widget.override_background is deprecated. How should I replace it? I > read something about CSS, but not sure how to do it... > Yes, the effort is large unfortunately. Maybe you can continue using the deprecated functions. Some months ago I wrote a small color test tool in Nim: https://github.com/ngtk3/nim-gtk3/blob/master/test/colors.nim I think I found some basic code snippets at stackoverflow. The styleContextAddProviderForScreen() function can really frighten one. But I think that is really the intended way. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Nim GTK3 editor
On Sun, 2016-07-10 at 15:54 +0200, Stefan Salewski wrote: > Maybe another one, but less important: I am using GSettings -- for > testing if the editor would work fine on a fresh install, I would > like > to reset all modifications done by my program. OK, that was not too difficult. http://unix.stackexchange.com/questions/8922/where-does-gsettings-store-its-files deleting /home/stefan/.config/dconf/user does the trick, which this new message (ned:2316): Gdk-CRITICAL **: gdk_rgba_parse: assertion 'spec != NULL' failed proves. So my fear was justified, before shipping a GTK app one has to test with virgin GSettings Seems that my app tries to access colors which are not already set by user in GSettings. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Nim GTK3 editor
Yesterday I pushed my Nim editor to github, see http://ssalewski.de/tmp/NEd.png https://github.com/ngtk3/NEd http://forum.nim-lang.org/t/2198 Lets try an easy question: I am using the font chooser button, which has default text (none) and later shows the name of the last opened file. For my use in the header bar, I would like to change that label, maybe to "Open" permanently. No chance? Maybe another one, but less important: I am using GSettings -- for testing if the editor would work fine on a fresh install, I would like to reset all modifications done by my program. No idea after googling for a few minutes -- when I create a new user and log in into that account I should get a clean environment I guess? The development up to this early stage was easy and fast, and indeed I was surprised how fine GtkSourceView works. OK, most of it, that idle scroll -- would be very hard without gedit sources... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Application.activate not emitted when opening files.
On Thu, 2016-06-16 at 20:12 +0200, Stefan Salewski wrote:
> I will see if I can find some C code for testing...
Well, looking at the C code of example10 is already enough:
gtk+-3.20.1/examples/application10
exampleapp.c
static void
example_app_activate (GApplication *app)
{
ExampleAppWindow *win;
win = example_app_window_new (EXAMPLE_APP (app));
gtk_window_present (GTK_WINDOW (win));
}
static void
example_app_open (GApplication *app,
GFile**files,
gint n_files,
const gchar *hint)
{
GList *windows;
ExampleAppWindow *win;
int i;
windows = gtk_application_get_windows (GTK_APPLICATION (app));
if (windows)
win = EXAMPLE_APP_WINDOW (windows->data);
else
win = example_app_window_new (EXAMPLE_APP (app));
for (i = 0; i < n_files; i++)
example_app_window_open (win, files[i]);
gtk_window_present (GTK_WINDOW (win));
}
static void
example_app_class_init (ExampleAppClass *class)
{
G_APPLICATION_CLASS (class)->startup = example_app_startup;
G_APPLICATION_CLASS (class)->activate = example_app_activate;
G_APPLICATION_CLASS (class)->open = example_app_open;
}
So your observed behaviour seems to be intended. When application is
started with arguments, example_app_open() is called, which includes
the code of example_app_activate(). This indicates that
example_app_activate() is not executed when application is started with
arguments, so we can assume that "activate" signal is not emitted for
that case. (That was not clear for me from the docs)
For testing, you may download gtk+ tar file, which includes
application10. Building only this one works with these commands
cd application10
glib-compile-schemas .
glib-compile-resources exampleapp.gresource.xml --target=resources.c
--generate-source
gcc -o main main.c resources.c exampleapp.c exampleappwin.c exampleappprefs.c
`pkg-config --libs --cflags gtk+-3.0`
A Nim version is also available, see
https://github.com/ngtk3/nim-app
http://forum.nim-lang.org/t/2198#13675
Unfortunately there seems to exist no Vala version yet.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Application.activate not emitted when opening files.
On Thu, 2016-06-16 at 14:44 -0300, Victor Aurélio Santos wrote:
> > You may follow the example https://developer.gnome.org/gtk3/stable/
> ch01s04.html#id-1.2.3.12.5
> Look at application code, I think it's very like the example you give
> me.
>
> > This way you are not concerned with signals that match.
> I can't understand what you mean.
Sorry, should be "that much" of course. For example, in
https://developer.gnome.org/gtk3/stable/ch01s04.html
they have
static void
example_app_class_init (ExampleAppClass *class)
{
G_APPLICATION_CLASS (class)->activate = example_app_activate;
G_APPLICATION_CLASS (class)->open = example_app_open;
}
So example_app_open() is called when the application is started with
arguments and example_app_activate() when started without. There is no
direct reference to any signals.
Unfortunately your example is in Vala, so we can not be sure that the
problem is not vala specific.
I will see if I can find some C code for testing...
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Application.activate not emitted when opening files.
On Wed, 2016-06-15 at 12:42 -0300, Victor Aurélio Santos wrote: > where should i do application's > basic things like creating windows, setting-up basic things etc... You may follow the example https://developer.gnome.org/gtk3/stable/ch01s04.html#id-1.2.3.12.5 This way you are not concerned with signals that match. From https://developer.gnome.org/gio/unstable/GApplication.html#GApplication -activate I would assume that that signal is emitted ALWAYS on the primary instance when an activation occurs. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK3 bindings for Nim language available
On Mon, 2015-03-30 at 14:50 +0200, Stefan Salewski wrote: > We have some basic Nim GTK3 bindings available now, see > > https://github.com/StefanSalewski?tab=repositories Bindings for GTK 3.20 are available now, I created a new top level directory at github for the ten modules: https://github.com/ngtk3 If you do not already know Nim language: http://nim-lang.org/ And some comments for the 3.20 Bindings: http://forum.nim-lang.org/t/2198 http://ssalewski.de/tmp/toychess.png ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How does one get the screen coordinates of the workspace?
On Tue, 2015-12-29 at 17:26 -0500, Rick Berger wrote: > I'm looking for to get the screen coordinates, height and width of the > workspace on Ubuntu's desktop. The only way I see to doing this, is in > starting the app: maximize its window; get the workspace info from its > window's coordinates and dimensions; then un-maximize its window. I > believe these can be done with GDK. > > Is there better way to do this? > I can remember that exactly that was a minimal example for my Nim GDK3 bindings. See https://github.com/StefanSalewski/nim-gdk3/blob/master/test/test.nim ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: set custom entry background?
On Sun, 2015-11-15 at 19:30 -0500, Allin Cottrell wrote: > But how can I "undo" this? (I mean, make it so that the background > color for the selected state reverts to what it was before I messed > with it, for subsequent selections.) That's trivial with the old > APIs but I have no idea how it can be done now. You may see https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-get-st yle-context https://developer.gnome.org/gtk3/stable/GtkStyleContext.html#gtk-style-c ontext-remove-provider No time to test it, sorry. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: set custom entry background?
On Sun, 2015-11-15 at 14:32 -0500, Allin Cottrell wrote: > I'm trying to set a custom background for a GtkEntry I think you have to use CSS -- unfortunately that is some work and I can not provide an example yet. See https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-overri de-background-color ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkComboBox signals
On Sun, 2015-10-25 at 18:35 +0100, Pekka Riikonen wrote:
> second one with "changed" signal on the combobox isn't because the
> signal
> is emitted also when typing into the entry. It effectively becomes
> impossible to determine whether item was typed in or selected from the
> list.
OK, no answer from experts yet.
I can remember that I used this Ruby code for that task:
@changed_handler_id = self.signal_connect('changed') {|w|
if @pda
if w.active != -1
i = w.active_text.to_i
if i != (@major ? @pda.schem.major_grid : @pda.schem.minor_grid)
if @major then @pda.schem.major_grid = i else @pda.schem.minor_grid = i
end
@pda.schem.active_grid = i if radio_button.active?
@pda.redraw
end
end
end
}
So active property of
https://developer.gnome.org/gtk3/stable/GtkComboBox.html#GtkComboBox--active
can be used to detect if an item was selected from list.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: TypeError in GtkWindow
On Thu, 2015-10-08 at 22:05 -0300, Germán Racca wrote: > About "coor.run()", I have followed the exact steps in the official > PyGObject tutorial: > > https://python-gtk-3-tutorial.readthedocs.org/en/latest/dialogs.html#c > ustom-dialogs Good to know :-) Well, I do not know much about Python. But the difference seems to be obviously. You have class TitleBar: and call coor = Coor2MASS(self) So for you self is not a widget at all, but it should, it is used as parent widget! In the Python tutorial we have class DialogWindow(Gtk.Window): Here self is a Gtk.Window. Can not say you exactly how to solve your problems, but you should get the idea. Or maybe ask in a Python list/forum when Python itself is the problem. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_text_buffer_delete ?
On Thu, 2015-10-08 at 10:30 +0200, Pierre Wieser wrote:
> Oop's. Sorry ! I've clicked on the bad button !!
Yes, it is sad that this trivial task is so hard, and that no one can
really help.
I was hoping that it could be possible to simple block input when buffer
has a maximum length, but I got that not working.
But deleting works at least.
https://developer.gnome.org/gtk3/stable/GtkTextBuffer.html#GtkTextBuffer
-insert-text
>Note that if your handler runs before the default handler it must not
>invalidate the location iter (or has to revalidate it).
So our callback have to reset the iter!
I did some test in Nim, a change to test my bindings and become some
more comfortable with that language. There we have
discard g_signal_connect_after(buffer, "insert-text", g_callback(clip), nil)
proc clip*(buffer: TextBuffer, iter: TextIter; text: cstring; len: gint; data:
gpointer) {.cdecl.} =
const max = 8
var i, j: TextIterObj
var cc = buffer.char_count
if cc > max:
buffer.get_iter_at_offset(i, cc)
j = i # copy iter object
discard j.backward_chars(cc - max)
buffer.delete(j, i)
buffer.get_iter_at_offset(iter[], max) # set iter to valid value again,
value seems to be arbitray
So the trick is just the last line, reset the iter callback parameter to
a valid value after deletion. It is strange, I have the feeling that the
callback is executed after the new text was already inserted, but in
spite of that gtk complains about invalid iter. Strange. I guess you can
understand the idea of that Nim code. I connected to "insert-text"
signal, so no danger of recursion. I used g_signal_connect_after here,
seems to make more sense when we delete last char. g_signal_connect
works similar, but we seem to get one char more? Maybe Emmanuele Bassi
can comment on this later...
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: TypeError in GtkWindow
On Thu, 2015-10-08 at 17:09 -0300, Germán Racca wrote: > --> 134 coor = Coor2MASS(self) I do not use Python, but that line seems to make no sense. Self is class TitleBar: but later you call resp = coor.run(). So I guess for coor you want something like a dialog, so you have to create it. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Filechooserbuttons and gtk_widget_set_sensitive
On Thu, 2015-10-08 at 14:04 +1030, Roger Matthews wrote: > To someone willing to help, Of course the file chooser example from the book of Andrew Krause does not really open a file. What should it open? A Video, a picture, a text? It shows you how you can get a file path, if I remember correctly. For a text file, you may use that path and load the text in a textview. Maybe that is shown in the book also. gtk_widget_set_sensitive() should work. And the example what you refer to, it may be this: https://developer.gnome.org/gtk3/stable/ch01s04.html#id-1.2.3.12.5 Yes that is GTK3 application style using builder and XML files. I have just made a Nim version from that. Does work fine, but I do not understand all currently. Converting that into a version without builder should be some hard work. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_text_buffer_delete ?
On Wed, 2015-10-07 at 13:14 +0200, Pierre Wieser wrote: > Hello, > > On the application I'm currently working on [1], I want limit the size > of the > text entered in a GtkTextBuffer to those saved in the DBMS, so 4096 > chars. Seen that: http://www.gtkforums.com/viewtopic.php?t=1012 Very similar to your solution, but I think that was GTK2, and your is GTK3. No other idea, sorry. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_text_buffer_delete ?
On Wed, 2015-10-07 at 13:14 +0200, Pierre Wieser wrote: > I so connected to the 'changed' signal of the GtkTextBuffer, Maybe try connecting to insert-text signal -- changed signal may be emitted again when you delete. See http://stackoverflow.com/questions/2791035/how-do-i-set-buffer-limit-for -gtk-text-view-in-c ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK3 on Windows 8.1: Touch Events Problem
On Sat, 2015-09-26 at 19:15 +0100, Emmanuele Bassi wrote: > Hi; > > GTK 3.6 is not the latest version for Windows. We don't provide > binary > packages any more, but you can use the MSYS2 project to get a build > of the > latest stable version of GTK - one that is not hopelessly out of date > like > 3.6, which was released 3.5 years ago. > > Ciao, > Emmanuele. I have the strong feeling that most people think that 3.6 is the latest supported version for Windows. And they are very disappointed. You may know that I was working on the Nim Bindings for GTK3, see https://github.com/StefanSalewski?tab=repositories Recently I got this: https://github.com/StefanSalewski/nim-gtk3/issues/3 I told that man from China that versions of GTK3 > 3.6 may be available for windows. But it seems what they see is 3.6 as binary only. I got more such report. Can not really help, because I am using Linux only currently. Maybe that MSYS2 project should be made more visible for Windows users. Most windows users seem to be using binaries only, and are afraid when something is not binary. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A simple choice dialog won't work...
On Thu, 2015-05-07 at 13:02 +0100, Richard Shann wrote:
From https://developer.gnome.org/gtk3/stable/GtkDialog.html
GTK_RESPONSE_REJECT Generic response id, not used by GTK+ dialogs
GTK_RESPONSE_ACCEPT Generic response id, not used by GTK+ dialogs
Maybe try
GTK_RESPONSE_OK and GTK_RESPONSE_CANCEL
If that does not help, I may test your code next weekend --guess I have
to add a few lines to get a working example.
I wanted to pop up two buttons for the user to choose between two
options (primary and secondary), returning true or false depending
which was chosen. I tried this
gboolean
choose_option (gchar *title, gchar * primary, gchar * secondary)
{
GtkWidget *dialog;
dialog = gtk_dialog_new_with_buttons (title,
GTK_WINDOW (Denemo.window),
(GtkDialogFlags) (GTK_DIALOG_MODAL |
GTK_DIALOG_DESTROY_WITH_PARENT),
primary, GTK_RESPONSE_ACCEPT,
secondary,GTK_RESPONSE_REJECT,
NULL);
g_signal_connect_swapped (dialog, response, G_CALLBACK
(gtk_widget_destroy), dialog);
return (gtk_dialog_run (GTK_DIALOG (dialog)) == GTK_RESPONSE_ACCEPT);
}
but it seems to return 0 for both button presses. What am I doing wrong?
I'm using GTK3 on a Debian stable installation.
Richard
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: A simple choice dialog won't work...
On Thu, 2015-05-07 at 16:02 +0100, Richard Shann wrote: After experimenting with a different bit of code, I think I've found the cause of the problem: doing the widget destroy by responding to the response signal seems to be ruining the return value. That is interesting. Indeed I had a feeling in that direction -- but not an exact idea what may went wrong. Unfortunately testing that takes a few minutes of time, and I am not really experienced with plain C code, I generally use Ruby or Nim. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Help spinbuttons, Paulo Silva
On Thu, 2015-04-09 at 23:17 +0930, Roger Matthews wrote:
Hi Paulo, or anybody else interested in helping,
I've read chapter 2 of Foundations of GTK+ Development concerning
signals and callback functions as suggested (see below) but am still
getting this error:
Hello,
I think you used wrong parameters for your callback function: Try this
modified example:
#include stdio.h
#include gtk/gtk.h
static void get_new_number(GtkWidget *widget, gpointer data)
{
float value;
value = gtk_spin_button_get_value(GTK_SPIN_BUTTON(widget));
printf(value = %f\n, value);
}
int main(int argc, char *argv[])
{
GtkWidget *window, *spin_float;
GtkAdjustment *float_pt;
gtk_init (argc, argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_set_size_request (window, 150, 100);
float_pt = GTK_ADJUSTMENT (gtk_adjustment_new (0.5, 0.0, 1.0, 0.1, 0.5,
0.5));
spin_float = gtk_spin_button_new (float_pt, 0.1, 1);
gtk_container_add (GTK_CONTAINER (window), spin_float);
gtk_widget_show_all (window);
g_signal_connect (spin_float, value-changed, G_CALLBACK
(get_new_number), NULL);
gtk_main ();
return 0;
}
$ gcc t.c -o test `pkg-config --cflags --libs gtk+-3.0`
$ ./test
value = 0.40
value = 0.30
value = 0.20
Please note that there was no callback to close the window in your
example, so we have to press CTRL C to terminate the program. Generally,
if you already have the Krause book, you may find examples for Spin
Buttons too, maybe not printed completely, but full code should be
available in Internet somewhere. But it is GTK2 still.
And note that you do not have to use C language for GTK toolkit -- there
are bindings available fpr many other languages, some have even
tutorials, i.e. Ruby or Python. These may be easier for beginners.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_widget_queue_draw_area much slower in gtk3 than gtk3
On Sun, 2015-03-29 at 22:16 -0700, dmg wrote: Hi there, I am one of the developers of xournal. Hello, if I understand correctly, your problem is, that shapes drawn on screen are not smooth. I can remember a related thread, see https://mail.gnome.org/archives/gtk-list/2014-August/thread.html where the problem seems to be more the low rate of input events. It may well be related to your task, because with input events only every 12 ms it is hard to draw smooth shapes. I have never further investigated this task, because it does not really concerns my application currently. (I was only concerned about smooth moving objects, but for moving we are always limited by 60 Hz screen refresh rate, so input events every 12 ms is OK. But I would really like being able doing smooth free hand drawing) It is interesting that you observed a difference in behaviour to GTK2. In case that you should not get an answer from a smart developer soon, it may really help making a minimal example for your observation, preferable in plain C, and maybe send the question to gtk-list too. You may start with the GTK3 scribble window from https://developer.gnome.org/gtk3/3.0/gtk-getting-started.html maybe modify it that it draws plain points or thin line segments. Obviously this problem my depend on hardware and OS strongly! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk_widget_queue_draw_area much slower in gtk3 than gtk3
On Mon, 2015-03-30 at 13:22 +0100, Emmanuele Bassi wrote: * use the event history for the devices you're interested in * disable motion event compression on the GdkWindow that you're using to detect events, and build up the positions you will then draw Other painting applications opted for the latter solution, so you should likely explore it first; see the API reference: For my Gentoo Linux box with gtk+-3.14.9 disabling motion event compression seems to have no effect currently. I just took the example program gtk+-3.15.8/examples/drawing.c and added the two inner lines gtk_widget_show_all (window); gdk_window = gtk_widget_get_window(GTK_WIDGET(window)); gdk_window_set_event_compression(gdk_window, FALSE); gtk_main (); (I think I have to put it after show all, to ensure that gtk window is realized and gdk window exists.) Makes no difference for me -- when I move the mouse pointer fast, I get separated points but no continuous line. I did a similar tests earlier, hoped that it would work now with GTK 3.14. I just tested with gimp -- with that tool free hand drawing gives continuous lines instead of separated points. So my mouse or other input hardware, and X event handling seems to be not the problem. There must be still some event filtering of GTK3 involved. Later I may test using event history... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Label with fixed size
On Thu, 2014-08-28 at 18:14 +0200, rastersoft wrote:
Hi all:
I need to create a label with a fixed size in pixels, and if the text is
too large, elipsize it. Is it possible? I tried nearly all kind of ways
and tricks (even capturing the size-allocate signal and adjust there the
maximum-character property until the size is fine), but can't get it.
Thanks.
When you REALLY need this, you may try the GTK Fixed container.
It allows to position widgets at absolute positions, and at the same
time, it prevents widgets from expanding itself.
Try the Ruby code below -- for me it always displays Not a... even
when I resize the main window. Of course you may read the documentation
of the Fixed container.
require 'gtk3'
window = Gtk::Window.new
window.border_width = 10
window.set_default_size(80, -1)
window.signal_connect(destroy) {Gtk.main_quit}
f = Gtk::Fixed.new
l = Gtk::Label.new('Not a long text')
l.set_size_request(50, -1)
l.ellipsize = Pango::ELLIPSIZE_END
#f.put(l, 0, 0)
f.add(l)
window.add(f)
window.show_all
Gtk.main
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK application scene drawing
On Sun, 2014-08-03 at 11:20 +0530, Gurjot Singh Bhatti wrote: Your project looks nice. Is it open-source? Sure. It started as a proof of concept, to test my user interface ideas, and how fine Ruby, Cairo and GTK works together. Generally I am satisfied, but in the last years I have done mostly very experimental coding to test thinks, so I generated really ugly code, which I have to cleanup now... I have something similar in my mind in context to that Grid and drawing entities. But so far I am just able to draw points on my drawingArea and and now working on how to detect if there is already a point under mouse. This is because I want to draw line when 2 points are already drawn and I select them. With zooming and panning there is some math involved. I started with a simple test application: http://ssalewski.de/PetEd-Demo.html.en (Was written for Ruby 1.8, for 2.0 some fixes may be necessary) A similar very basic library in C should be available somewhere -- I really think someone told us about such thing on gtk or cairo mailing lists. But I can not remember the name and I can not find it in the mails... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK application scene drawing
On Sun, 2014-08-03 at 16:13 +0200, Stefan Salewski wrote: A similar very basic library in C should be available somewhere OK -- found it. It was this thread https://mail.gnome.org/archives/gtk-app-devel-list/2014-June/msg00011.html and this was a reply mentioning the library https://mail.gnome.org/archives/gtk-app-devel-list/2014-June/msg00016.html https://code.google.com/p/bridgegl/ So it is called BridgeGL. I have never looked at it, but it may help you? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK application scene drawing
On Sun, 2014-08-03 at 00:21 +0530, Gurjot Singh Bhatti wrote: This may have been asked many times already Yes, in the last years a have found a few similar questions with google, in most cases not with VERY helpful replies. I myself have used cairo with a GTK drawing area for my schematics tool, and it was not a bad choice for that task: It gives me all the freedom I need for that application, it looks fine and is fast enough -- I am not sure if Ruby or cairo is currently more the limiting factor, I guess both. (I am using bounding boxes for my objects and redraw only when content has changed. http://www.ssalewski.de/PetEd.html.en) I think your general conclusion is right, but you do not report about a few important aspects: First, when you have already experience with Qt, why do you not use QGraphicsView? I heard it is fine -- for C++ it may be a good choice, for other languages you have to check if bindings are available -- I think not for Rust or Ninrod, for Julia, Haskell I am not sure. One important aspect may be drawing performance. Cairo in not very fast by default, I think OpenGl and multi-treading support is limited, at least I found no nice examples for really fast drawing. And generally OpenGl for GTK is not very well supported -- GTKGLEXT may work with GTK3, but I am not sure and there is not much recent activity. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkGrid sets no expand with homogeneous
On Wed, 2014-04-02 at 19:40 +0900, Takao Fujiwara wrote: I'd like to port GtkTable to GtkGrid but my cells show big widths. Have you considered this: https://developer.gnome.org/gtk3/stable/GtkGrid.html Description GtkGrid is a container which arranges its child widgets in rows and columns. It is a very similar to GtkTable and GtkBox, but it consistently uses GtkWidget’s “margin” and “expand” properties instead of custom child properties, My guess is that you should set your buttons “expand” property to false. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Re:Help replacing GtkDrawingArea with GtkLayout
On Mon, 2014-03-03 at 15:17 +, Richard Shann wrote: I have constructed the following minimal example, Yes indeed, https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-events This function must be called while a widget is unrealized. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Re:Help replacing GtkDrawingArea with GtkLayout
On Mon, 2014-03-03 at 15:17 +, Richard Shann wrote: gtk_widget_show_all (window); GdkWindow *win = gtk_widget_get_window(layout); g_print(win is %p initial mask 0x%x\n, win, gdk_window_get_events (win)); gdk_window_set_events (win, gdk_window_get_events (win) | GDK_STRUCTURE_MASK); g_print(After adding GDK_STRUCTURE_MASK mask 0x%x\n, gdk_window_get_events (win)); gtk_widget_add_events (layout, GDK_ALL_EVENTS_MASK); Just a stupid guess, sorry: May it be necessary to set event mask BEFORE displaying the window with gtk_widget_show_all (window); ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Mouse events on a Cairo Context
On Mon, 2013-07-01 at 17:42 +0200, Borja Mon Serrano wrote: The problem with (4) is dragdrop. I think it could be very difficult to deal with it, so I'm going to try the third solution, with goocanvasmm. Do you know any example of use of goocanvasmm? Yes, dragdrop may be not very easy. And zooming and panning/scrolling for a plain (cairo) drawing area may be not really trivial, when you need to grab objects with the mouse. I did try it two years ago from Ruby -- not really difficult, but it takes some time to get the math right. Have not found time to clean it up yet. ( http://www.ssalewski.de/PetEd.html.en) Of course, if you do C++ and have not much experience in GTK already you may try https://qt-project.org/doc/qt-4.8/graphicsview.html I have never find time and motivation to test that. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Hiding scrollbars for GtkScrolledWindow
On Fri, 2013-06-07 at 19:05 +0200, Felix Möller wrote: Sorry for being unprecise. GTK3 in combination with C. If I set the scrollbars' policy to never, the scrollbar is not displayed, but the window is not as small as it should be, but as big as its content. I want it to have the same size as with scrollbars, but without displaying them. Have you got any helpful advice already? I think that using a GtkScrolledWindow may be not a good choice if you do not want the visible scrollbars -- a GtkViewport may be what you want? But still I wonder why hiding the Scrollbars of a GtkScrolledWindow is not possible. Of course there may exists good reasons for that. Would be nice to know them. I have not found a C example code for GTK3 GtkScrolledWindow, so I have not examined that problem (Ruby bindings work not really well for GTK3 yet) -- maybe when I have more time. Best regards Stefan Salewski ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Hiding scrollbars for GtkScrolledWindow
On Fri, 2013-06-07 at 10:13 +0200, Felix Möller wrote: Hey there, I'm trying to use a GtkScrolledWindow with the capability of scrolling, but not displaying scroll bars GTK3 or GTK2? Called from C or Python? This may help: https://developer.gnome.org/gtk3/stable/GtkScrolledWindow.html#gtk-scrolled-window-set-policy ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Hiding scrollbars for GtkScrolledWindow
On Fri, 2013-06-07 at 19:05 +0200, Felix Möller wrote: Sorry for being unprecise. GTK3 in combination with C. If I set the scrollbars' policy to never, the scrollbar is not displayed, but the window is not as small as it should be, but as big as its content. I want it to have the same size as with scrollbars, but without displaying them. Sorry, I can not really help you in this case. Have you seen this old post http://python.6.x6.nabble.com/Hide-scrollbar-td1941146.html But it may be for GTK2 only. Of course one can use scrolling without a GtkScrolledWindow -- I have used a GTK Drawing area long time ago (http://www.ssalewski.de/PetEd-Demo.html.en) but of course that is not what you want. If no one can answer you question here, you may ask at gtk-l...@gnome.org. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Handle Enter pressing at GtkEntry
On Wed, 2012-10-03 at 20:18 +0200, David Nečas wrote: On Wed, Oct 03, 2012 at 09:42:24AM -0500, Yury Alyaev wrote: What is the right way to catch Enter pressing at the end of the text input to GtkEntry. The obvious way is conecting the callback to the activate signal, but for some reason documentation says Applications should not connect to it. My Gtk+ documentation says the opposite: ...it is also commonly used by applications to intercept activation of entries. and I've been using it for a long time without problems. Yeti I asked a similar question some time ago https://mail.gnome.org/archives/gtk-list/2012-March/msg00033.html Seems that the irritating statement Applications should not connect to it, but may emit it... http://developer.gnome.org/gtk/stable/GtkEntry.html#GtkEntry-activate is removed for current GTK3. Thanks. http://developer.gnome.org/gtk3/stable/GtkEntry.html#GtkEntry-activate ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: learning GtkLayout, drawing a widget on it.
On Mon, 2012-08-20 at 03:09 +0200, ben wrote: Hello list, It may be a basic and common question, but i dare to ask... I began to write a custom widget, subclassing GtkDrawingArea, An alternative approach may be to just use a GTK drawing area with cairo drawing operations as I did http://www.ssalewski.de/PetEd-Demo.html.en http://www.ssalewski.de/PetEd.html.en There was a similar question on gtk-list recently: https://mail.gnome.org/archives/gtk-list/2012-July/msg00025.html ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GtkDrawingArea size
On Wed, 2012-03-07 at 09:44 -0900, Christopher Howard wrote: X Bump. I'm trying to look through some other projects to see how this is done, but I would appreciate it if anyone happens to know of the top of their head. I guess you can have a drawingarea of fixed size if you put it in a container of fixed size, ie. make the window fixed size, see http://developer.gnome.org/gtk3/stable/GtkWindow.html#GtkWindow--resizable With cairo it is easy to scale your graphics, and you get all these nice stuff like anti-aliasing, transparency and much more. But cairo is not very fast -- for my current toy project (http://www.ssalewski.de/PetEd.html.de) I had to carefully figure out which redraw operation is really necessary for updating the display. A complete redraw can take more than 100ms -- but now I have fixed that by using bounding boxes for each elements, and redrawing only what has changed. But for fast action games OpenGL may be a better choice. When your application does not need fast graphics, then you may also consider other languages than C -- I am using Ruby currently, next time I may give Vala a try... ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: TreeView tooltip use immediate control
On Sat, 2012-02-04 at 00:01 +0100, David Nečas wrote: On Fri, Feb 03, 2012 at 11:36:13PM +0100, Stefan Salewski wrote: How can I immediately activate or deactivate tooltips for all TreeView widgets on user action, i.e. menu operation. You can enable/disable all tooltips using the gtk-enable-tooltips GtkSettings property. But if you want to enable/disable them just for some specific of widgets you have to handle it yourself. The easiest method is probably making the widgets query your enable/disable setting in their query-tooltip signal handlers – and then return TRUE or FALSE from the handlers. Yeti Sorry, I may need some more help... I was not able to suppress the tooltips by returning FALSE from the signal handler -- in my Ruby code. So I took the listview.c example from Andrew Krauses book, added tooltip support. That works. Then I added a query-tooltip signal handler returning FALSE -- but tooltips are further shown. The handler is called, I checked it with a printf statement inside the handler. The C code is here: http://www.ssalewski.de/tmp/liststore.c I used this function to add tooltips http://developer.gnome.org/gtk3/stable/GtkTreeView.html#gtk-tree-view-set-tooltip-column My current guess is, that it is not possible to suppress tooltips for a treeview by a query-tooltip signal handler. Maybe the handler is called after the tooltip is displayed, or called for each row/column of the treeview? But maybe I am doing something wrong, I have not much experience in C GTK programming. Best regards, Stefan Salewski ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
TreeView tooltip use immediate control
I have an application which use many TreeView widgets (see http://www.ssalewski.de/PetEd.html.en). I use set_tooltip_column() to activate tooltips at program start when widgets are created. How can I immediately activate or deactivate tooltips for all TreeView widgets on user action, i.e. menu operation. It should not be necessary to terminate and restart the program. Of course I can use a list of all TreeView widgets for accessing all and use set_tooltip_column()... But I guess I should solve this problem by using events? Which GTK event is best used for this modification? Or should I emit an event myself, when user wants to toggle tooltip display? I have no idea currently. Thanks, Stefan Salewski ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: TreeView tooltip use immediate control
On Sat, 2012-02-04 at 00:01 +0100, David Nečas wrote: On Fri, Feb 03, 2012 at 11:36:13PM +0100, Stefan Salewski wrote: How can I immediately activate or deactivate tooltips for all TreeView widgets on user action, i.e. menu operation. You can enable/disable all tooltips using the gtk-enable-tooltips GtkSettings property. I guess this works on all applications of the Gnome/GTK desktop? Maybe not what the user wants... But if you want to enable/disable them just for some specific of widgets you have to handle it yourself. The easiest method is probably making the widgets query your enable/disable setting in their query-tooltip signal handlers – and then return TRUE or FALSE from the handlers. Yeti Thanks, this sounds good. I was not aware that this query-tooltip handler is involved at all when I only use a simple gtk_tree_view_set_tooltip_column() (http://developer.gnome.org/gtk3/stable/GtkTreeView.html#gtk-tree-view-set-tooltip-column) I will test it. Best reagards, Stefan Salewski ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GTK+ TreeView: Different CellRenderers on the same Column
I am working on a configuration file editor for an graphical application. Configuration consists of strings, numbers and boolean values. About 25 values total. I can use individual widgets for each property, but for larger quantities a listview is a more compact form. It would we nice to have textentry fields for strings, spin buttons for numbers and check boxes for boolean values, all in one column of the tree view. Of course I can pop up dialog windows whenever the user clicks on an row of the treeview, but that is not a nice solution when the user wants to change more than one value. With Google, I found some people asking for this, but only one complicated solution: http://kapo-cpp.blogspot.com/2008/05/different-cellrenderers-on-same-column.html I think it is too complicated for me now, not being an GTK expert. (And I am using the Ruby GTK bindings, which may make it difficult to use the above solution.) Is there a better solution or even an example available? Best Regards, Stefan Salewski ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK+ TreeView: Different CellRenderers on the same Column
On Mon, 2011-10-17 at 15:11 +0200, Colomban Wendling wrote: [...] The other solution I know is to pack all CellRenderer that might be used for editing, and only make one visible/sensitive, depending on the row's value type. This is what we current use in the implementation of Geany's stash editor [2], [3]. Thanks, that sound very promising and not too difficult. I was aware that I can pack multiple renderer in the same tree view column, but I was not aware that I can hide them totally using a cell_data_func. Best regards, Stefan Salewski ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Cairo, Gtk+, Gdk GdkPixbuf -- making a pixel-based backing store for vector graphics
On Tue, 2011-06-14 at 14:30 -0600, James Tappin wrote: I would like to be able to make a code that draws some (possibly very complex) vector graphics, A better place for asking may be the cairo mailing list? At least there was some discussion about such tasks in the past. One recommended way was using cairos create_similar() function for creating the backup surface. I did a small demo in Ruby some time ago, see http://www.ssalewski.de/PetEd-Demo.html.en I found this related thread with some helpful replies: http://lists.freedesktop.org/archives/cairo/2009-March/016756.html But I am still interested in smarter solutions. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Window styles
On Thu, 2011-05-26 at 18:14 +0100, John Emmas wrote: Using gtk_window_new() will create a window which the user can re-size and maximize. I don't want my user to be able to perform these actions. In my old Win32 days I'd achieve it by creating a window, then removing the styles WS_THICKFRAME and WS_MAXIMIZEBOX. How do I achieve this with gtk? John http://developer.gnome.org/gtk/stable/GtkWindow.html Is gtk_window_set_resizable and similar not working for you? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
How to avoid POINTER_MOTION events for not active windows?
I am working on a simple linux/gnome/gtk/cairo/ruby application similar to http://www.ssalewski.de/PetEd-Demo.html.en I want to get POINTER_MOTION events when mouse pointer is in my GTK drawing area. When I call add_events() for my drawing area with flag Gdk::Event::POINTER_MOTION_MASK I get motion events whenever the mouse pointer is over/in my drawing area, even when the window containing that drawing area is not active. This was surprising for me. I want events only when the window is the active one. What is the correct method to achieve that behavior? Thanks, Stefan Salewski ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
