Re: Setting the scroll position of a GtkTextView in GtkScrolledWindow after render

2019-04-08 Thread Stefan Salewski
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

2018-03-30 Thread Stefan Salewski
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

2018-03-30 Thread Stefan Salewski
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

2018-03-30 Thread Stefan Salewski
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

2018-03-29 Thread Stefan Salewski
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

2018-03-10 Thread Stefan Salewski
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.

2018-02-26 Thread Stefan Salewski
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

2018-02-23 Thread Stefan Salewski
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

2017-09-13 Thread Stefan Salewski
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

2017-09-13 Thread Stefan Salewski
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

2017-09-09 Thread Stefan Salewski
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

2017-09-03 Thread Stefan Salewski
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

2017-07-23 Thread Stefan Salewski
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

2017-05-29 Thread Stefan Salewski
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

2017-03-30 Thread Stefan Salewski
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

2017-03-30 Thread Stefan Salewski
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

2017-03-30 Thread Stefan Salewski
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

2017-03-30 Thread Stefan Salewski
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

2017-03-29 Thread Stefan Salewski
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

2017-03-29 Thread Stefan Salewski
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

2017-03-29 Thread Stefan Salewski
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

2017-03-29 Thread Stefan Salewski
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

2017-03-22 Thread Stefan Salewski
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

2017-03-16 Thread Stefan Salewski
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

2017-03-16 Thread Stefan Salewski
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

2017-03-10 Thread Stefan Salewski
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

2017-03-08 Thread Stefan Salewski
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

2017-03-08 Thread Stefan Salewski
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

2017-03-08 Thread Stefan Salewski
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

2017-03-08 Thread Stefan Salewski
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

2017-03-08 Thread Stefan Salewski
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

2017-03-08 Thread Stefan Salewski
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

2017-03-07 Thread Stefan Salewski
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

2016-11-12 Thread Stefan Salewski
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

2016-08-23 Thread Stefan Salewski
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

2016-08-22 Thread Stefan Salewski
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

2016-08-18 Thread Stefan Salewski
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

2016-07-10 Thread Stefan Salewski
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

2016-07-10 Thread Stefan Salewski
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.

2016-06-16 Thread Stefan Salewski
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.

2016-06-16 Thread Stefan Salewski
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.

2016-06-16 Thread Stefan Salewski
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

2016-04-22 Thread Stefan Salewski
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?

2015-12-29 Thread Stefan Salewski
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?

2015-11-16 Thread Stefan Salewski
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?

2015-11-15 Thread Stefan Salewski
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

2015-10-28 Thread Stefan Salewski
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

2015-10-09 Thread Stefan Salewski
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 ?

2015-10-08 Thread Stefan Salewski
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

2015-10-08 Thread Stefan Salewski
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

2015-10-08 Thread Stefan Salewski
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 ?

2015-10-07 Thread Stefan Salewski
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 ?

2015-10-07 Thread Stefan Salewski
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

2015-09-26 Thread Stefan Salewski
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...

2015-05-07 Thread Stefan Salewski
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...

2015-05-07 Thread Stefan Salewski
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

2015-04-09 Thread Stefan Salewski
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

2015-03-30 Thread Stefan Salewski
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

2015-03-30 Thread Stefan Salewski
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

2014-08-28 Thread Stefan Salewski
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

2014-08-03 Thread Stefan Salewski
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

2014-08-03 Thread Stefan Salewski
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

2014-08-02 Thread Stefan Salewski
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

2014-04-02 Thread Stefan Salewski
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

2014-03-03 Thread Stefan Salewski
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

2014-03-03 Thread Stefan Salewski
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

2013-07-01 Thread Stefan Salewski
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

2013-06-09 Thread Stefan Salewski
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

2013-06-07 Thread Stefan Salewski
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

2013-06-07 Thread Stefan Salewski
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

2012-10-03 Thread Stefan Salewski
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.

2012-08-20 Thread Stefan Salewski
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

2012-03-07 Thread Stefan Salewski
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


Arrow speed (tic rate) of scrollbar widgets

2012-03-02 Thread Stefan Salewski
Is there a way to set the speed (tic rate, repetition frequency) for
scrollbar widgets when LMB is pressed over the arrow keys?

I have used this C example for testing:

http://developer.gnome.org/gtk-tutorial/stable/x743.html

When pressing the left mouse button on the arrow keys of the scrollbar
widget (the second from top on the right) the slider moves soft but
slow. I know I can use middle or right mouse button for larger steps,
but I want a faster smooth scroll. ( I guess what I need is a higher
event rate, the default seems to be limited to 10 per second.)

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: TreeView tooltip use immediate control

2012-02-04 Thread Stefan Salewski
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

2012-02-03 Thread Stefan Salewski
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

2012-02-03 Thread Stefan Salewski
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

2011-10-17 Thread Stefan Salewski
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

2011-10-17 Thread Stefan Salewski
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

2011-06-14 Thread Stefan Salewski
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

2011-05-26 Thread Stefan Salewski
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?

2011-03-10 Thread Stefan Salewski
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