Re: Making a GtkSeparator more visible

[Felipe Borges]

Hi,

On Wed, Nov 29, 2017 at 11:30 PM,   wrote:
>  How can I make a GtkSeparator more visible.  I guess that means making it
> darker and / or thicker

You could make it thicker by increasing its height_request property to
a proper value.

You could make it darker by setting some css properties for its css
node, such as:

separator {
  background-color: #000;
}

There are other ways to achieve it, these are just suggestions off the
top of my head.

>
>  Thanks
>  Doug
>
> ___
> 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: Set CSS properties programmatically

[Felipe Borges]

Hello,

On Sat, Nov 25, 2017 at 5:03 PM, -  wrote:
> Hello,
>
> Can you please share a link to your current approach? Doesn't sound
> efficient but makes sense. I'd like to run the code and see the animation in
> action.

Yes. It is being used in GNOME Usage performance panel
https://gitlab.gnome.org/GNOME/gnome-usage
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Set CSS properties programmatically

[Felipe Borges]

Hi,

I have been looking for a clean way of updating my widget's css
properties programmatically at runtime.

Basically I have a css animation which gets its properties from
variables in my C code.

The current (working) approach I came up with is to benefit from the
cascade and generate a whole new css definition for the animation
every time my variable changes and use GtkStyleProvider.load_from_css
(my_new_animation_css_spec). For this to work I need to set the
"animation-name" to have a new and unique value, overwriting the
previous one. This doesn't sound efficient at all.

My desire is to get the "animation" property of my class, and be able
to update only what changes in it. It can already be done for some
properties via GtkStyleContext.get_property.

All in all, is there a better way of doing this? Will there ever be?

Thanks,
Felipe.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: No protocol specified error

[Felipe Borges]

whatever man

On Sat, Oct 21, 2017 at 2:25 AM, David Margerison
<del...@electrosonics.com.au> wrote:
> On 20 October 2017 at 22:33, Felipe Borges <felipe10bor...@gmail.com> wrote:
>>
>> Running GUI applications as root is hardly discouraged.
>
> The English language can be surprising, so I write this short note to help
> avoid confusion.
>
> 400 years ago, your sentence above would be correct. But the meaning
> of the word "hardly" has changed over time.
>
> In modern language, your sentence above means: running GUI applications
> as root is discouraged only a small amount.
>
> (I suspect that is the opposite of what you wanted to say).
>
> Because these days "hardly" means "not very much".
>
> If a glass of water is almost empty, we can say: there is hardly any
> water there.
>
> The word "hardly" has lost its original connection to the word "hard".
>
> So I would write that sentence as:
>   Running GUI applications as root is severely discouraged.
> or
>   Running GUI applications as root is strongly discouraged.
> ___
> 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: No protocol specified error

[Felipe Borges]

On Fri, Oct 20, 2017 at 1:18 PM, Lokesh Chakka
<lvenkatakumarcha...@gmail.com> wrote:
> Dear Felipe,
>
> Thanks for the information.
> Is it possible to login with my credentials and execute as sudo ./a.out.
>
> Can u help me how to make it work ?

Running GUI applications as root is hardly discouraged.

What you should be going for is to develop an application which runs
as a normal user and uses PolicyKit[0] to gain administrator
privileges whenever is necessary.

[0] https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html

>
>
>
>
> Thanks & Regards
> --
> Lokesh Chakka,
> Mobile: 9731023458
>
> On Fri, Oct 20, 2017 at 4:43 PM, Felipe Borges <felipe10bor...@gmail.com>
> wrote:
>>
>> On Fri, Oct 20, 2017 at 1:01 PM, Lokesh Chakka
>> <lvenkatakumarcha...@gmail.com> wrote:
>> > Hello,
>> >
>> > I am using simple program
>> >
>> > #include 
>> >
>> > int main(int argc, char *argv[])
>> > {
>> > GtkWidget *window;
>> > gtk_init(NULL, NULL);
>> > window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
>> > gtk_widget_show(window);
>> > g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit),
>> > NULL);
>> > gtk_main();
>> > return 0;
>> > }
>> >
>> > I compiled it using gcc simple.c `pkg-config --cflags gtk+-3.0 --libs`
>> > if I do ./a.out, GUI is showing up.
>> >
>> > but if I do "sudo ./a.out", I am seeing the following error :
>> >
>> > 
>> > $ sudo ./a.out
>> > No protocol specified
>> > Unable to init server: Could not connect: Connection refused
>> >
>> > (a.out:7961): Gtk-WARNING **: cannot open display: :0
>> > 
>> >
>> > As my application back end needs root privileges, I need to open the GUI
>> > using sudo only.
>> > Can some one help in fixing this issue ?
>> >
>> > The same code was working fine in Ubuntu 17.04. But I am facing this
>> > issue
>> > after upgrading to Ubuntu 17.10.
>>
>> Ubuntu 17.10 has switched to the Wayland display server, which is
>> designed to fix the security issues existent in X.
>>
>> Wayland only allows the user who started the X server to connect clients
>> to it.
>>
>> For more info, see https://bugzilla.redhat.com/1266771
>>
>> >
>> > Thanks
>> > --
>> > Lokesh Chakka,
>> > Mobile: 9731023458
>> > ___
>> > 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: No protocol specified error

[Felipe Borges]

On Fri, Oct 20, 2017 at 1:01 PM, Lokesh Chakka
 wrote:
> Hello,
>
> I am using simple program
>
> #include 
>
> int main(int argc, char *argv[])
> {
> GtkWidget *window;
> gtk_init(NULL, NULL);
> window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
> gtk_widget_show(window);
> g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
> gtk_main();
> return 0;
> }
>
> I compiled it using gcc simple.c `pkg-config --cflags gtk+-3.0 --libs`
> if I do ./a.out, GUI is showing up.
>
> but if I do "sudo ./a.out", I am seeing the following error :
>
> 
> $ sudo ./a.out
> No protocol specified
> Unable to init server: Could not connect: Connection refused
>
> (a.out:7961): Gtk-WARNING **: cannot open display: :0
> 
>
> As my application back end needs root privileges, I need to open the GUI
> using sudo only.
> Can some one help in fixing this issue ?
>
> The same code was working fine in Ubuntu 17.04. But I am facing this issue
> after upgrading to Ubuntu 17.10.

Ubuntu 17.10 has switched to the Wayland display server, which is
designed to fix the security issues existent in X.

Wayland only allows the user who started the X server to connect clients to it.

For more info, see https://bugzilla.redhat.com/1266771

>
> Thanks
> --
> Lokesh Chakka,
> Mobile: 9731023458
> ___
> 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: TypeError in GtkWindow

[Felipe Borges]

As mentioned by Stefan, Coor2MASS was expecting a GtkWindow (the
parent window), and you are passing a TitleBar object.

Try something like this:

diff --git a/q2MASS.py b/q2MASS.py
index 43af88c..6b6a6d7 100644
--- a/q2MASS.py
+++ b/q2MASS.py
@@ -37,7 +37,7 @@ class Query2MASS(Gtk.Window):
 self.set_border_width(10)

 # add headerbar
-tb = TitleBar()
+   tb = TitleBar(self)
 titlebar = tb.headerbar()
 self.set_titlebar(titlebar)

@@ -62,7 +62,9 @@ class Query2MASS(Gtk.Window):
 class TitleBar:
 """Create the header bar"""

-def __init__(self):
+def __init__(self, parent):
+self.parent = parent
+
 """Initialize the class"""
 # create left and right headers
 self.left_header = Gtk.Grid()
@@ -131,7 +133,7 @@ class TitleBar:
 def on_button_coor_clicked(self, widget):
 """Close popover and show Coordinates options"""
 self.popover_opts.hide()
-coor = Coor2MASS(self)
+   coor = Coor2MASS(self.parent)
 resp = coor.run()
 if resp == Gtk.ResponseType.OK:
 print("Clicked OK!")
-- 

On Fri, Oct 9, 2015 at 1:21 PM, Stefan Salewski  wrote:
> 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
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: How should I structure a full screen, modal kiosk app (newbie)

[Felipe Borges]

Hey,

Have you thought about using multiple GtkStacks and switching with a
GtkStackSwitcher? Take a look at Stack on the gtk3-demo application.

On Sat, May 9, 2015 at 12:27 PM, Mike South mso...@gmail.com wrote:
 I'm using Perl GTK on a debian-based distro.  My app is the only
 user-visible thing running.

 The app is logically organized into screens.  A run screen (which is
 showing most of the time), a menu screen (with buttons to change things),
 a help screen (shows text describing app function).

 I am an experienced perl programmer, but a complete GTK newbie.  When I
 switch screens, I hide/remove the widgets I had previously added, and
 build the screen I need to show (by adding the appropriate widgets for that
 screen to the window).

 It's a pretty simple app, almost all of what it does is display text, so
 the drawing time is not really an issue.

 However, I'm pretty sure this is not how to do this.

 Details of my (probably bad) current implementation:

 I have a single window:

 my $window = Gtk2::Window-new('toplevel');

 I set that window to full screen:

 $window-fullscreen;

 Then, when I switch screens in the application, I remove/hide widgets
 currently showing, and create and add the widgets for the current view (I'm
 sorry if you just threw up in your mouth a little when reading that.)

 There is no mouse or keyboard--I have to switch screens manually in
 response to other things in the environment (voltage on gpio pins).

 What should I be doing?  Should each screen of the app be its own
 $window, with the widgets generated once, then -show and -hide on the
 $windows to switch between screens?  Will multiple toplevel, fullscreen
 windows coexist ok?  But, more importantly, is that the way to do it, as
 in, the way an experienced GTK developer would do it?  Or is there
 something like panes/views/whatever that are children of windows, and I
 should be switching between them?

 Thanks, and sorry for the complete newbieness of the question.

 Pointers to documentation I may have missed in my searching are also
 welcome.

 mike
 ___
 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

No Pascal in the Gtk bindings list?

[Felipe Monteiro de Carvalho]

Hello,

Please add Pascal in the Gtk bindings page:
http://www.gtk.org/language-bindings.php

FPC supports all versions listed there except version 3.0 (which is under work)

You can add a link to this page:
http://wiki.lazarus.freepascal.org/GTK2_Interface

thanks,
-- 
Felipe Monteiro de Carvalho
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [PATCH] [RFC] Add g_*_deinit() API

[Felipe Contreras]

On Wed, Sep 29, 2010 at 4:46 PM, Ole André Vadla Ravnås
ole...@gmail.com wrote:
 I'm currently working on adding API to GLib/GObject/GIO for explicitly
 cleaning up statically allocated resources, like TLS keys, threads,
 handles, heap blocks, etc.

That would be really great... Perhaps GLib would finally be valgrind friendly :)

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GCancellable is not really cancellable?

[Felipe Contreras]

Hi Alexander,

On Mon, Apr 26, 2010 at 2:59 PM, Alexander Larsson al...@redhat.com wrote:
 On Sun, 2010-04-25 at 22:05 +0300, Felipe Contreras wrote:

 So what am I supposed to do? ref() the object each time I do an async
 operation, and unref() it each time the operation finishes, while also
 keeping an extra field in order to find out if the object has been
 disposed?

 Depends on what you mean by object. The stream itself is automatically
 refed when there is an outstanding async operation on it. If you have
 further data that you need to live until the callback then you have to
 ref it, or otherwise keep it alive.

By object I mean my custom object that I passed through user_data.

 What's the point? Wouldn't it be better to truly cancel the operation?

 This is how cancellation worked in gnome-vfs, and it has a few problems.

This how all I/O API's I know work; GIOChannel, libpurple, libevent.
They have no problems.

 First of all, its inherently and unfixably racy in the multi-threaded
 case. For instance, what if you call cancel() on a thread when the
 operation just finished and we've called the callback on another cpu.
 There is no way at this point to stop that emission, and its not
 reasonably possible to synchronize and have the cancel fail.

That's what mutexes are for. The cancel() function would wait until
the emission finishes.

 Secondly, its not always possible to immediately cancel an i/o
 operation, and the data passed to such an operation (for instance the
 destination buffer) need to stay around until the operation is really
 done, or you might be scribbling over random memory.

Ditto.

 Third, code wise its actually not simpler, because you now get two
 codepaths that free the data that was allocated for the data (free in
 callback, or free after cancelling). This leads to convoluted code that
 is hard to get right. With gio you can *always* assume the callback will
 be called, and only once, so you can free any data there.

If you want to free the data in the callback, then don't call
cancel(). Or make cancel() wait until the callback function has been
called, and then continue.

Perhaps a better solution would be to have a separate discard()
function that would cancel(), discard the results, and wait for the
callback to finish if it's in progress.

I don't think this scenario, where an object has ownership of a
GAsyncResult operation and updates itself on the callback, is uncommon
at all, and the current API is clearly not suited for this. If I want
to kill the operation, I should be able to, otherwise resources will
be wasted.

Cheers.

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GCancellable is not really cancellable?

[Felipe Contreras]

On Mon, Apr 26, 2010 at 4:35 PM, Alexander Larsson al...@redhat.com wrote:
 On Mon, 2010-04-26 at 16:04 +0300, Felipe Contreras wrote:
 On Mon, Apr 26, 2010 at 2:59 PM, Alexander Larsson al...@redhat.com wrote:
  This is how cancellation worked in gnome-vfs, and it has a few problems.

 This how all I/O API's I know work; GIOChannel, libpurple, libevent.
 They have no problems.

 GIOChannel have no cancellation api. I don't really know the other apis.

After calling g_io_channel_shutdown() no further callbacks happen.

  First of all, its inherently and unfixably racy in the multi-threaded
  case. For instance, what if you call cancel() on a thread when the
  operation just finished and we've called the callback on another cpu.
  There is no way at this point to stop that emission, and its not
  reasonably possible to synchronize and have the cancel fail.

 That's what mutexes are for. The cancel() function would wait until
 the emission finishes.

 So, you want want the cancellation operation to block the mainloop until
 the worker thread has finished cancelling the operation, a potentially
 very slow i/o operation? That seems like a very bad idea. It certainly
 would make it useless for any gui code.

So would g_input_stream_read_all(), that's not a reason to remove API
that would be potentially useful for non gui code.

  Third, code wise its actually not simpler, because you now get two
  codepaths that free the data that was allocated for the data (free in
  callback, or free after cancelling). This leads to convoluted code that
  is hard to get right. With gio you can *always* assume the callback will
  be called, and only once, so you can free any data there.

 If you want to free the data in the callback, then don't call
 cancel(). Or make cancel() wait until the callback function has been
 called, and then continue.

 Again, sync cancel is not what you want.

Why not? Are you assuming all code is for gui? A separate
cancel_sync(), or discard() would do the trick for non-gui code.

 I don't think this scenario, where an object has ownership of a
 GAsyncResult operation and updates itself on the callback, is uncommon
 at all, and the current API is clearly not suited for this. If I want
 to kill the operation, I should be able to, otherwise resources will
 be wasted.

 I don't see the problem? Just free the data in the callback, whether
 cancelled or not. Any wasting of resources is just until the callback
 gets called on the mainloop, which should be more or less instant if
 immediate cancallation is possible.

The data is owned by a parent object, which I don't know if it's still
there or not. The big waste of resources is in the extra ref'ing and
unref'ing each time an async operation is issued. This could be solved
if there was a way of detecting when the source object is being
destroyed (after all the async operations have finished).

Cheers.

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Moving GLib and GTK+ to git

[Felipe Contreras]

2009/4/6 Kristian Høgsberg k...@redhat.com:
 On Fri, 2009-04-03 at 02:28 +0200, Philipp wrote:
 /lurk

 Kristian Høgsberg wrote:
  Just an update on my plan to possibly rebase the gtk+ repo: not going to
  happen.  What we have now is a good compromise between keeping all
  history in the most correct form and how much work we want to put into
  it.  Again, no data is lost, we just have a few tags with some extra
  files in them.
 How about deleting the broken tags from the git repos and keeping a
 little note somewhere buried deep in the docs/ dirs. Someone who cares
 about digging through history (like me) will then know to hit the
 historical CVS / SVN repositories for these specific missing tags.

 Its not like someone is going to re-roll tarballs from these tags ever
 again (or at least the chance is ~ ɛ).

 I don't see a good reason to delete the tags.  They take virtually no
 storage, and are mostly accurate except for the extra files.  Last but
 not least, they're a great help when browsing through history since most
 repo viewers will annotate commits with the tag or branch if one or more
 exists (for example, the GTK_2_16_0 tag on this page:
 http://git.gnome.org/cgit/gtk+/log/?ofs=50)

It would be better if you used more git compliant tags like v2.16.0.
Those tags make sense, but BEFORE_FEDERICO_FILENAME_ENTRY_MERGE... I
don't think so.

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Moving GLib and GTK+ to git

[Felipe Contreras]

On Fri, Apr 3, 2009 at 10:04 AM, Edward Hervey bilb...@gmail.com wrote:
 On Tue, 2009-03-31 at 21:29 +0200, Martin Nordholts wrote:
 Matthias Clasen wrote:
   - First line (the brief description) must only be one sentence and
     must not start with a capital letter. Don't use a trailing period
     either. Don't exceed 76 characters.

 Hi,

 Is there any particular reason for not starting with a capital letter,
 e.g. are there any tools that depend on it? In general I think a
 sentence look nicer if it starts with a capital letter, including those
 that does not end with a period. From a quick look at the most recent
 commit messages for the Linux kernel and git itself, it does not seem as
 if they have a rule such as the one above, which makes me even more
 curious why we should have it.

  FWIW, In GStreamer git repositories we use that same rule for the
 one-liner with a subtle variation:
  * We do allow capital letters (seriously, who cares? It looks nice)
  * Considering you want to have as much info as possible in that
 one-liner, we try to prefix it with a word giving a clue as to where the
 work was done (without looking at the modified files). Doesn't apply if
 it's a change accross the whole module.
  Ex :
   rtspsrc: allow http:// on the proxy setting, or
   Mark unused arguments using G_GNUC_UNUSED glib macro.

This is also the guideline used in git.git, and it looks pretty good:

id: fix foobar

or if there's no id:

Generic cleanup

Note that no full-stop is used.

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Cross-compiling GLib 2.18 with arm-linux.

[Felipe Contreras]

On Sat, Mar 28, 2009 at 4:42 PM, John Peterson j0...@comcast.net wrote:
 Dear Felipe,

 Thanks for the response.  I'm not quite sure how to figure out what arm 
 compiler I'm using.  This came as part of a toolkit to support building 
 applications for an SBC1625 embedded controller from Micro/sys.

 When I try to determine the version, this is what I get:


 [jo...@fingerrock17 host]$ arm-linux-gcc --version
 arm-linux-gcc (GCC) 3.2.1
 Copyright (C) 2002 Free Software Foundation, Inc.
 This is free software; see the source for copying conditions. There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


 I've tried just about everything to get the compiler to recognize/handle the 
 asm directive, but no dice.  It sure feels like it's not supported with my 
 compiler.  :-(

Well, it looks like it's very old =/

My bet is you would need to do many changes to remove the asm code.

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GIO and sockets

[Felipe Contreras]

On Thu, Sep 4, 2008 at 4:29 AM, Dan Winship d...@gnome.org wrote:
 Felipe Contreras wrote:
 How should applications use sockets with GIO?

 I'm interested in hostname resolution, and socket handling. If
 possible also proxy handling.

 There isn't yet a good story here. See
 http://bugzilla.gnome.org/show_bug.cgi?id=515973 and
 http://bugzilla.gnome.org/show_bug.cgi?id=548466.

 One possibility that's available now is to use SoupAddress and
 SoupSocket from libsoup, and just ignore the HTTP parts of the library.
 This is what the gvfs ftp backend does (although gvfs already depended
 on libsoup anyway, so it was an easy decision to make there).

Sorry I didn't respond to this mail. I've been following those bug
reports. Thanks.

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GHashTable and const

[Felipe Contreras]

On Thu, Jul 10, 2008 at 7:00 PM, Andrew W. Nosenko
[EMAIL PROTECTED] wrote:
 On Thu, Jul 10, 2008 at 5:17 PM, Havoc Pennington [EMAIL PROTECTED] wrote:
 Hi,

 On Thu, Jul 10, 2008 at 6:10 AM, Andrew W. Nosenko
 [EMAIL PROTECTED] wrote:
 Sorry for long delay, but could you please explain, how changing from
g_hash_table_size (GHashTable *hash_table);
 to
g_hash_table_size (const GHashTable *hash_table);
 would to break any C++ code?  It would to make some bunch of
 const_cast unneeded and noop -- yes.  But break...  hard to imagine.


 Anything assigning or passing in g_hash_table_size as a function
 pointer would break.

 Yes, indeed... :-(

I don't get it, can you explain how exactly?

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: proposal about glib

[Felipe Contreras]

2008/6/29 Johan Dahlin [EMAIL PROTECTED]:
 Havoc Pennington wrote:
 Hi,

 2008/6/25  [EMAIL PROTECTED]:
 1）I use glib's main event loop, but why glib's main event loop don't support
 epoll/kqueue?

 The GLib event loop has been designed to handle a low number of file
 descriptors. Typical Gtk+ applications uses only 1 file descriptor (the X
 connection).

GLib isn't used only on GTK+ applications.

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Steps to get to GTK+ 3.0

[Felipe Contreras]

On Mon, Jun 9, 2008 at 3:30 PM, Martyn Russell [EMAIL PROTECTED] wrote:
 Murray Cumming wrote:
 On Tue, 2008-06-03 at 13:34 +0200, Kristian Rietveld wrote:
 [snip]
 We should start to enforce the usage of single header includes and not
 make this optional.  Mitch has been working on this and most is already in
 place in SVN trunk.
 [snip]

 What's the advantage of this? Has this been a real problem for GTK+ so
 far?

 The main advantages I can think of are:

 - When you add/remove/rename header files, you don't break all
 applications which directly included them.
 - Application developers don't have to worry about which files
 specifically they need to include, they just include the project header
 file. This makes using GTK+ a lot easier for beginners.
 - If you stop using a widget in a source file but forget to remove the
 include statement, it leaves cruft in applications.

 I don't know if it is a problem. But GLib does it and we should be
 consistent one way or the other.

 Many people (particularly C++ developers) like to reduce pollution of
 the global namespace by including as few headers as reasonably possible.
 That can also reduce compile times (particularly for C++ developers).

 I prefer one header. Like #include glib.h

 I know it affects compile time, but it simplifies things for application
 developers and makes maintenance much easier and I consider that much
 more important.

Why not leave the choice to the application developers? Something a
general-purpose utility library should avoid is patronizing the
clients, right?

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: glib and Xlib

[Felipe Contreras]

2008/6/6 jaafar EL GONNOUNI [EMAIL PROTECTED]:
 Hello;

 What is glib adding that the GTK + compared to Xlib ?

 All what is possible with glib with Xlib is feasible, then why create a new
 library.

GObject for example.

-- 
Felipe Contreras
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: glib and Xlib

[Felipe Contreras]

2008/6/6 jaafar EL GONNOUNI [EMAIL PROTECTED]:
 Hello;

 What is glib adding that the GTK + compared to Xlib ?

 All what is possible with glib with Xlib is feasible, then why create a new
 library.

GObject for example.

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Steps to get to GTK+ 3.0

[Felipe Contreras]

On 6/5/08, Jean-Yves Lefort [EMAIL PROTECTED] wrote:

 Sure, both systems need some reflection capabilities, which neither C
  nor C++ support natively. I don't see how this point would debunk the
  fact that C++ is a more expressive language than C, and that writing
  an object-oriented application in C++ is generally easier and more
  pleasant than writing it in C.

  I know that C++ has its share of issues, and I do understand why in
  the nineties, the GLib people decided to use C and not C++. I actually
  agree with their decision. Yet, if some people claim that Qt is
  superior because it chose C++, trying to disprove them with the above
  argument is like trying to oppose general relativity with because my
  aunt Lilly likes to drink tea.

I'm not familiar with Qt, I only repeat what I've heard; Qt is
superior because it renders faster. Planing to solve the issues in
GTK+ that will improve performance is useful, advocating C++ is not.

I doubt 3.0 will be in C++, 4.0, and possibly any other release. Can
we focus on productive discussions?

Best regards.

P.S. Me, and many developers hate C++ with passion, if a toolkit
requires C++, it's cutting a huge user-base.

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [PATCH] Use autopoint for GLib

[Felipe Contreras]

2008/5/7 Jean-Yves Lefort [EMAIL PROTECTED]:
 On Wed, 07 May 2008 01:02:02 +0100
  Bastien Nocera [EMAIL PROTECTED] wrote:

  
   On Tue, 2008-05-06 at 16:54 -0700, Brian J. Tarricone wrote:
Bastien Nocera wrote:
 On Tue, 2008-05-06 at 19:41 -0400, Havoc Pennington wrote:
 Hi,

 On Tue, May 6, 2008 at 4:15 PM, Felipe Contreras
 [EMAIL PROTECTED] wrote:
  Is there any reason?

 I don't know. If I had to guess, it probably wasn't seen as worth
 maintaining. After all none of the other features of GLib have random
 --disable-feature options. Searching in bugzilla might find related
 bug discussion.

 And also because glib provides i18n for applications and libraries 
 above
 it, and convenience functions for UTF-8, etc. that wouldn't be 
 available
 on Unix systems without NLS support.
   
Disabling NLS support might be quite useful for people on embedded
systems and/or people who are using glib for only a part of their
application and use a different translation framework.
  
   And it means that a lot of convenience functions for UTF-8 handling
   wouldn't work.

  Just FYI, that's not true. The GLib Unicode code does not require
  gettext. Unicode support and message translation support are two
  entirely different matters.

Exactly.

AFAIK the only effect is that the messages from GLib won't be
translated. For clients using the library there's no difference at
all.

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[PATCH] Use autopoint for GLib

[Felipe Contreras]

Hi,

I noticed disable-nls wasn't available so I dug until I came with a solution.

I'm attaching a patch that makes use of autopoint and seems to work fine.

I would have created a bug report but the bug reporting form is a joke [1].

Best regards.

[1] http://bugzilla.gnome.org/simple-bug-guide.cgi

-- 
Felipe Contreras
Index: configure.in
===
--- configure.in	(revision 6879)
+++ configure.in	(working copy)
@@ -433,24 +433,23 @@
 dnl gettext support
 dnl
 
-ALL_LINGUAS=am ar as az be [EMAIL PROTECTED] bg bn bn_IN bs ca cs cy da de dz el en_CA en_GB eo es et eu fa fi fr ga gl gu he hi hr hu hy id is it ja ka kn ko ku lt lv mg mk ml mn mr ms nb ne nl nn oc or pa pl pt pt_BR ro ru rw si sk sl sq sr [EMAIL PROTECTED] [EMAIL PROTECTED] sv ta te th tl tr tt uk vi wa xh yi zh_CN zh_HK zh_TW
-GLIB_GNU_GETTEXT
+AM_GNU_GETTEXT_VERSION([0.11.5])
+AM_GNU_GETTEXT([external])
 
-if test $gt_cv_have_gettext != yes ; then
-  AC_MSG_ERROR([
-*** You must have either have gettext support in your C library, or use the 
-*** GNU gettext library. (http://www.gnu.org/software/gettext/gettext.html
-])
+if test $USE_NLS = yes; then
+	GETTEXT_PACKAGE=[glib20]
+else
+	GETTEXT_PACKAGE=[NULL]
 fi
 
-LIBS=$INTLLIBS $LIBS
-
-GETTEXT_PACKAGE=glib20
 AC_SUBST(GETTEXT_PACKAGE)
-AC_DEFINE_UNQUOTED(GETTEXT_PACKAGE, [$GETTEXT_PACKAGE], 
-  [Define the gettext package to be used])
+AC_DEFINE_UNQUOTED([GETTEXT_PACKAGE], $GETTEXT_PACKAGE,
+		   [Define the gettext package to be used])
 
-GLIB_DEFINE_LOCALEDIR(GLIB_LOCALE_DIR)
+dnl define LOCALEDIR in config.h
+AS_AC_EXPAND(LOCALEDIR, $datadir/locale)
+AC_DEFINE_UNQUOTED([GLIB_LOCALE_DIR], $LOCALEDIR,
+		   [Define the location where the catalogs will be installed])
 
 dnl
 dnl Now we are done with gettext checks, figure out ICONV_LIBS
Index: m4/as-ac-expand.m4
===
--- m4/as-ac-expand.m4	(revision 0)
+++ m4/as-ac-expand.m4	(revision 0)
@@ -0,0 +1,43 @@
+dnl as-ac-expand.m4 0.2.0
+dnl autostars m4 macro for expanding directories using configure's prefix
+dnl [EMAIL PROTECTED]
+
+dnl AS_AC_EXPAND(VAR, CONFIGURE_VAR)
+dnl example
+dnl AS_AC_EXPAND(SYSCONFDIR, $sysconfdir)
+dnl will set SYSCONFDIR to /usr/local/etc if prefix=/usr/local
+
+AC_DEFUN([AS_AC_EXPAND],
+[
+  EXP_VAR=[$1]
+  FROM_VAR=[$2]
+
+  dnl first expand prefix and exec_prefix if necessary
+  prefix_save=$prefix
+  exec_prefix_save=$exec_prefix
+
+  dnl if no prefix given, then use /usr/local, the default prefix
+  if test x$prefix = xNONE; then
+prefix=$ac_default_prefix
+  fi
+  dnl if no exec_prefix given, then use prefix
+  if test x$exec_prefix = xNONE; then
+exec_prefix=$prefix
+  fi
+
+  full_var=$FROM_VAR
+  dnl loop until it doesn't change anymore
+  while true; do
+new_full_var=`eval echo $full_var`
+if test x$new_full_var = x$full_var; then break; fi
+full_var=$new_full_var
+  done
+
+  dnl clean up
+  full_var=$new_full_var
+  AC_SUBST([$1], $full_var)
+
+  dnl restore prefix and exec_prefix
+  prefix=$prefix_save
+  exec_prefix=$exec_prefix_save
+])
Index: autogen.sh
===
--- autogen.sh	(revision 6879)
+++ autogen.sh	(working copy)
@@ -100,14 +100,15 @@
   fi
 fi
 
-$ACLOCAL $ACLOCAL_FLAGS || exit $?
+$ACLOCAL -I m4 $ACLOCAL_FLAGS || exit $?
 
-libtoolize --force || exit $?
+autopoint --force || exit $?
+libtoolize --force --copy || exit $?
 gtkdocize || exit $?
 
 autoheader || exit $?
 
-$AUTOMAKE --add-missing || exit $?
+$AUTOMAKE --add-missing --copy || exit $?
 autoconf || exit $?
 cd $ORIGDIR || exit $?
 
Index: po/LINGUAS
===
--- po/LINGUAS	(revision 0)
+++ po/LINGUAS	(revision 0)
@@ -0,0 +1 @@
+am ar as az be [EMAIL PROTECTED] bg bn bn_IN bs ca cs cy da de dz el en_CA en_GB eo es et eu fa fi fr ga gl gu he hi hr hu hy id is it ja ka kn ko ku lt lv mg mk ml mn mr ms nb ne nl nn oc or pa pl pt pt_BR ro ru rw si sk sl sq sr [EMAIL PROTECTED] [EMAIL PROTECTED] sv ta te th tl tr tt uk vi wa xh yi zh_CN zh_HK zh_TW
Index: po/Makevars
===
--- po/Makevars	(revision 0)
+++ po/Makevars	(revision 0)
@@ -0,0 +1,41 @@
+# Makefile variables for PO directory in any package using GNU gettext.
+
+# Usually the message domain is the same as the package name.
+DOMAIN = $(GETTEXT_PACKAGE)
+
+# These two variables depend on the location of this directory.
+subdir = po
+top_builddir = ..
+
+# These options get passed to xgettext.
+XGETTEXT_OPTIONS = --keyword=_ --keyword=N_
+
+# This is the copyright holder that gets inserted into the header of the
+# $(DOMAIN).pot file.  Set this to the copyright holder of the surrounding
+# package.  (Note that the msgstr strings, extracted from the package's
+# sources, belong to the copyright holder of the package.)  Translators are
+# expected to transfer

Re: [PATCH] Use autopoint for GLib

[Felipe Contreras]

On Tue, May 6, 2008 at 10:38 PM, Claudio Saavedra
[EMAIL PROTECTED] wrote:
 El mar, 06-05-2008 a las 22:08 +0300, Felipe Contreras escribió:

 
   I would have created a bug report but the bug reporting form is a joke
   [1].

  There's also http://bugzilla.gnome.org/enter_bug.cgi , reachable from
  the main menu in Bugzilla.

True, I didn't see it.

Too bad it can only be seen from the main page; the main menu links to
another form, and from that form there's no way to go to the advanced
one.

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [PATCH] Use autopoint for GLib

[Felipe Contreras]

On Tue, May 6, 2008 at 10:27 PM, Havoc Pennington [EMAIL PROTECTED] wrote:
 Hi,

  2008/5/6 Felipe Contreras [EMAIL PROTECTED]:

   I noticed disable-nls wasn't available so I dug until I came with a 
  solution.
  
I'm attaching a patch that makes use of autopoint and seems to work fine.
  
I would have created a bug report but the bug reporting form is a joke 
 [1].

  Try this one:
  http://bugzilla.gnome.org/enter_bug.cgi?product=glib

  I think disable-nls has been missing on purpose for many years though:
  http://mail.gnome.org/archives/gtk-devel-list/2002-January/msg00137.html

Is there any reason?

From that mail it seems it wasn't working.

-- 
Felipe Contreras
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Changing the style properties?

[Felipe]

Emmanuele Bassi wrote:
 On Mon, 2007-06-25 at 15:04 +0200, Felipe wrote:
 Hi,

 I want to remove the horizontal separators of a tree view, but the 
 corresponding property is read only[1]. I assume that this style 
 property can be changed in some way, but how?
 
 you can change the style properties only by parsing a new resource
 file/buffer. you don't want to do that, though, because it's the user's
 theme that should decide whether tree views should or should not have
 separators between rows.
 
 you can ship your own theme with your application, if that's what you
 want, but your app will always look out of place with the rest of gtk+
 applications running.
 
 ciao,
  Emmanuele.
 

Hi Emmanuele,

thanks. Now I know that the style properties are normally modified with 
the help of a resource file (that was very important). I will try to 
implement such a file in my application because my GUI looks really ugly 
with horizontal and vertical separators.

Thanks and if you know some howtos about the mentioned topic please let 
me know.


Felipe
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Changing the style properties?

[Felipe]

Hi,

I want to remove the horizontal separators of a tree view, but the 
corresponding property is read only[1]. I assume that this style 
property can be changed in some way, but how?


Thanks in advance,



Felipe



[1] http://developer.gnome.org/doc/API/2.0/gtk/GtkTreeView.html#id3104240
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

List view: Howto get the number of displayed rows?

[Felipe]

Hi,

Perhaps a stupid question, but I searched unsuccessfully in the 
documentation of GtkListStore and GtkTreeModel about the number of rows 
that are currently displayed in a list view. Now I need to know if 
exists a function for this or should I use gtk_tree_model_foreach() to 
count the number of rows manually?


Thanks in advance,


Felipe


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Global GladeXML

[Felipe Balbi]

Hello all,

my problem is the folowing...
I have a glade xml file being opened in my code...

I wanna use the same pointer to this XML file in other functions...
how could I do it??
I have the implementation below, but my signals are not connecting.. why??
(maybe this IS a newbie question... but I'm not figuring this out...
the purpose here is to make it easier if I wanna port the application
to other Graphical Interface Toolkit such as Maemo/Hildon, QT or even
text...)


/* Global Glade XML File */
static GladeXML *openhset;

/* Event Handlers */
void on_main_window_ok_clicked (GtkWidget *widget, gpointer data)
{
gtk_main_quit();
}

void on_main_window_quit_clicked (GtkWidget *widget, gpointer data)
{
printf( Calling Quit handler\n);
gtk_main_quit();
}

void on_main_window_destroy_event (GtkWidget *widget, gpointer data)
{
gtk_main_quit();
}

/* Custom interface functions */
void openhset_main(void)
{
gtk_main();
}

int openhset_fill_list(char **data)
{
GtkWidget   *treeview;
GtkListStore*list;
GtkTreeIter iter;
GtkCellRenderer *renderer;
GtkTreeViewColumn   *column;

treeview = glade_xml_get_widget (openhset, main_window_treeview1);
list = gtk_list_store_new (1, G_TYPE_STRING);
gtk_list_store_append (list, iter);
gtk_list_store_set (list, iter,
COLUMN, Testing new function,
-1);

gtk_tree_view_set_model (GTK_TREE_VIEW (treeview), GTK_TREE_MODEL 
(list));

renderer = gtk_cell_renderer_text_new();
column = gtk_tree_view_column_new_with_attributes (USB, renderer,
text, COLUMN, NULL);

gtk_tree_view_append_column (GTK_TREE_VIEW (treeview), column);

return 0;
}

int openhset_init_interface(int argc, char *argv[])
{
GtkWidget   *main_window, *test_window;
GtkWidget   *main_window_treeview1;
GtkWidget   *main_window_ok;

GtkListStore*main_window_list;
GtkTreeIter iter;

GtkCellRenderer *renderer;
GtkTreeViewColumn   *column;

gtk_init(argc, argv);

/* Open the XML File */
openhset = glade_xml_new (OPENHSET_XML, NULL, NULL);

/* Get Widgets */
main_window = glade_xml_get_widget (openhset, main_window);
main_window_ok = glade_xml_get_widget (openhset, main_window_ok);

return 0;
}


-- 
Best Regards,

Felipe Balbi
[EMAIL PROTECTED]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Global GladeXML

[Felipe Balbi]

Hi,

On 5/26/07, Jim George [EMAIL PROTECTED] wrote:
 On 5/26/07, Felipe Balbi [EMAIL PROTECTED] wrote:
  it's the glade_xml_signal_autoconnect
 
  I define the name in the xml file and code the same name in the C 
  language...
 
  libglade does the connections :-p
 
  easier.. and let my code be cleaner...
 

 You need to pass -export-dynamic to ld in order to let libglade see
 the symbols in your binary.

 This is being pedantic, but I didn't see glade_xml_signal_autoconnect
 in your code either :-)

yeah... I've commented on my tests and forgot to put it again...
when passing to the list i've removed the commented code
.. my bad...

now it's working fine..
i've made openhset_init_interface() return a GladeXML*... now I can
get it on the other side..
thanks


 -Jim

 PS, do a reply all, otherwise the mail only gets sent to me and not
 the mailing list.

K... it's this gmail... maybe I can maybe it always reply-all




-- 
Best Regards,

Felipe Balbi
[EMAIL PROTECTED]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Global GladeXML

[Felipe Balbi]

On 5/26/07, Felipe Balbi [EMAIL PROTECTED] wrote:
 Hi,

 On 5/26/07, Jim George [EMAIL PROTECTED] wrote:
  On 5/26/07, Felipe Balbi [EMAIL PROTECTED] wrote:
   it's the glade_xml_signal_autoconnect
  
   I define the name in the xml file and code the same name in the C 
   language...
  
   libglade does the connections :-p
  
   easier.. and let my code be cleaner...
  
 
  You need to pass -export-dynamic to ld in order to let libglade see
  the symbols in your binary.
 
  This is being pedantic, but I didn't see glade_xml_signal_autoconnect
  in your code either :-)

 yeah... I've commented on my tests and forgot to put it again...
 when passing to the list i've removed the commented code
 .. my bad...

 now it's working fine..
 i've made openhset_init_interface() return a GladeXML*... now I can
 get it on the other side..
 thanks

 
  -Jim
 
  PS, do a reply all, otherwise the mail only gets sent to me and not
  the mailing list.

 K... it's this gmail... maybe I can maybe it always reply-all

correcting... maybe i can make it always reply-all


 


 --
 Best Regards,

 Felipe Balbi
 [EMAIL PROTECTED]



-- 
Best Regards,

Felipe Balbi
[EMAIL PROTECTED]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

GtkTreeView: Simple application

[Felipe Balbi]

Hello all,

I'm starting an app to run Electrical Tests on the USB.
I'm not really good on GTK+ since I've always being developing on kernel-space.

my doubt regards this code:

int main(int argc, char *argv[])
{
GladeXML*openhset;
GtkWidget   *main_window, *test_window;
GtkWidget   *main_window_treeview1;
GtkWidget   *main_window_ok;

GtkListStore*main_window_list;
GtkTreeIter iter;

GtkCellRenderer *renderer;
GtkTreeViewColumn   *column;

struct usb_bus  *bus;

gtk_init(argc, argv);

/* Open the XML File */
openhset = glade_xml_new (OPENHSET_XML, NULL, NULL);

/* Get Widgets */
main_window = glade_xml_get_widget (openhset, main_window);
main_window_ok = glade_xml_get_widget (openhset, main_window_ok);
main_window_treeview1 = glade_xml_get_widget (openhset,
main_window_treeview1);

/* Connect signal handlers */
glade_xml_signal_autoconnect (openhset);

/* Create a GtkListStore */
main_window_list = gtk_list_store_new (1, G_TYPE_STRING);

/* Populate the GtkListStore */
gtk_list_store_append (main_window_list, iter);
gtk_list_store_set (main_window_list, iter,
0, TESTING,
-1);

/* Add the GtkListStore to the GtkTreeView */
gtk_tree_view_set_model (GTK_TREE_VIEW (main_window_treeview1),
GTK_TREE_MODEL (main_window_list));

/* Renderer and column */
renderer = gtk_cell_renderer_text_new();
column = gtk_tree_view_column_new_with_attributes (USB HCD, renderer,
text, 1, NULL);

gtk_tree_view_append_column (GTK_TREE_VIEW (main_window_treeview1), 
column);

gtk_main();

return 0;
}

So... I can't see the result of:

gtk_list_store_set (main_window_list, iter,
0, TESTING,
-1);

It's not being listed in the treeview after building / running the code.

What am I doing wrong??

-- 
Best Regards,

Felipe Balbi
[EMAIL PROTECTED]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkTreeView: Simple application

[Felipe Balbi]

Wow... thanks... :-)
Now I can keep going with my app...

thanks a lot :-)


On 5/26/07, David Nečas (Yeti) [EMAIL PROTECTED] wrote:
 On Sat, May 26, 2007 at 03:19:49AM +0300, Felipe Balbi wrote:
 
  my doubt regards this code:
 
  int main(int argc, char *argv[])
  {
GladeXML*openhset;
GtkWidget   *main_window, *test_window;
GtkWidget   *main_window_treeview1;
GtkWidget   *main_window_ok;
 
GtkListStore*main_window_list;
GtkTreeIter iter;
 
GtkCellRenderer *renderer;
GtkTreeViewColumn   *column;
 
struct usb_bus  *bus;
 
gtk_init(argc, argv);
 
/* Open the XML File */
openhset = glade_xml_new (OPENHSET_XML, NULL, NULL);
 
/* Get Widgets */
main_window = glade_xml_get_widget (openhset, main_window);
main_window_ok = glade_xml_get_widget (openhset, main_window_ok);
main_window_treeview1 = glade_xml_get_widget (openhset,
  main_window_treeview1);
 
/* Connect signal handlers */
glade_xml_signal_autoconnect (openhset);
 
/* Create a GtkListStore */
main_window_list = gtk_list_store_new (1, G_TYPE_STRING);
 
/* Populate the GtkListStore */
gtk_list_store_append (main_window_list, iter);
gtk_list_store_set (main_window_list, iter,
0, TESTING,
-1);
 
/* Add the GtkListStore to the GtkTreeView */
gtk_tree_view_set_model (GTK_TREE_VIEW (main_window_treeview1),
  GTK_TREE_MODEL (main_window_list));
 
/* Renderer and column */
renderer = gtk_cell_renderer_text_new();
column = gtk_tree_view_column_new_with_attributes (USB HCD, 
  renderer,
text, 1, NULL);

 Doesn't this print a warning to console?

 Your list store has only one column, which therefore gets
 number 0, and here you are trying to bind some renderer
 attribute to (nonexistent) column 1.

gtk_tree_view_append_column (GTK_TREE_VIEW (main_window_treeview1), 
  column);
 
gtk_main();
 
return 0;
  }
 
  So... I can't see the result of:
 
gtk_list_store_set (main_window_list, iter,
0, TESTING,
-1);
 
  It's not being listed in the treeview after building / running the code.

 Probably a consequence of the problem above -- the tree view
 has not actually got anything to display.

 Yeti

 --
 http://gwyddion.net/
 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



-- 
Best Regards,

Felipe Balbi
[EMAIL PROTECTED]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: [Gtk-sharp-list] How disable entire gnome desktop

[Felipe Almeida Lessa]

2005/12/11, Arx Henrique [EMAIL PROTECTED]:
 Hi all, i need disable all gnome-desktop

 when gnome-session initialize, i'll throw my program, and i need
 disable all gnome-desktop until the user close my app.

 anyone know how i could do this?

Maybe you should try using the .Xsession file. This way, instead of
messing up with the gnome-session, you just need to write a script.

 cheers

Cya,
Felipe.

--
Quem excele em empregar a força militar subjulga os exércitos dos outros
povos sem travar batalha, toma cidades fortificadas dos outros povos sem as
atacar e destrói os estados dos outros povos sem lutas prolongadas. Deve
lutar sob o Céu com o propósito primordial da 'preservação'. Desse modo suas
armas não se embotarão, e os ganhos poderão ser preservados. Essa é a
estratégia para planejar ofensivas.

  -- Sun Tzu, em A arte da guerra
___
Gtk-sharp-list maillist  -  Gtk-sharp-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: [Gtk-sharp-list] How disable entire gnome desktop

[Felipe Almeida Lessa]

Em 11/12/05, Arx Henrique[EMAIL PROTECTED] escreveu:
 the synaptic make this, in ubuntu, i dont know if is the gksu or
 synaptic, but when you click in show updates, they disable all desktop
 until you put the root passwd or click in cancel button.

Grab the keyboard and the mouse. Quoting SharpMusic's code (a program of mine):

private Window wnd; // This is your window
private bool TryGrab() {
Gdk.EventMask mask = Gdk.EventMask.ButtonPressMask
| Gdk.EventMask.ButtonReleaseMask
| Gdk.EventMask.PointerMotionMask;

Gtk.Grab.Add(wnd);

if (Gdk.Keyboard.Grab(wnd.GdkWindow, true, 0) != Gdk.GrabStatus.Success) {
Gtk.Grab.Remove(wnd);
return false;
}

if (Gdk.Pointer.Grab(wnd.GdkWindow, true, mask, null, null, 0) !=
Gdk.GrabStatus.Success) {
Gtk.Grab.Remove(wnd);
Gdk.Keyboard.Ungrab(0);
return false;
}

return true;
}

 i want this.

And here you have it. You may need to adjust the value of the mask
variable, but I don't know if or how. If that doesnt work, try with
Gdk.EventMask mask = Gdk.EventMask.AllEventsMask, maybe it works.

Cya,
Felipe.

--
Quem excele em empregar a força militar subjulga os exércitos dos outros
povos sem travar batalha, toma cidades fortificadas dos outros povos sem as
atacar e destrói os estados dos outros povos sem lutas prolongadas. Deve
lutar sob o Céu com o propósito primordial da 'preservação'. Desse modo suas
armas não se embotarão, e os ganhos poderão ser preservados. Essa é a
estratégia para planejar ofensivas.

  -- Sun Tzu, em A arte da guerra
___
Gtk-sharp-list maillist  -  Gtk-sharp-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: [Gtk-sharp-list] How disable entire gnome desktop

[Felipe Almeida Lessa]

2005/12/11, Felipe Almeida Lessa [EMAIL PROTECTED]:
 Grab the keyboard and the mouse. Quoting SharpMusic's code (a program of 
 mine):

I forgot the code to give back the control to the user =P:

private void Ungrab() {
Gtk.Grab.Remove(wnd);
Gdk.Pointer.Ungrab(0);
Gdk.Keyboard.Ungrab(0);
}

Use these functions like:
if (TryGrab()) {
try {
// Do what you have to do here
} finally {
Ungrab();
}
}

--
Quem excele em empregar a força militar subjulga os exércitos dos outros
povos sem travar batalha, toma cidades fortificadas dos outros povos sem as
atacar e destrói os estados dos outros povos sem lutas prolongadas. Deve
lutar sob o Céu com o propósito primordial da 'preservação'. Desse modo suas
armas não se embotarão, e os ganhos poderão ser preservados. Essa é a
estratégia para planejar ofensivas.

  -- Sun Tzu, em A arte da guerra
___
Gtk-sharp-list maillist  -  Gtk-sharp-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list