gmane.comp.gnome.devel

Re: json-glib problem

Emmanuele Bassi — 2013-05-23T09:43:23

hi;

On 23 May 2013 10:14, Aldrich Niklaus <aldrichnjit< at >gmail.com> wrote:

you forgot to initialize GError here:


you should set it to NULL:

  GError *error = NULL;

before passing it to json_parser_load_from_file();

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/

Re: json-glib problem

Emmanuele Bassi — 2013-05-23T07:48:05

hi;

On 23 May 2013 08:40, Aldrich Niklaus <aldrichnjit< at >gmail.com> wrote:



if you're using a recent version of GLib, calling g_type_init() is not
strictly necessary.


if you're walking through a JSON tree, then you can also use
JsonReader: its API should be slightly easier to use.


you should look at the stack trace of the segmentation fault by
running your program under gdb; just use:

    gdb --args ./your-demo-program

and type "bt" when the program aborts.

you'll see where the program crashes and hopefully why. in case, copy
the stack trace in a reply.

ciao,
 Emmanuele.

--
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi/
_______________________________________________
gnome-devel-list mailing list
gnome-devel-list< at >gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-devel-list

json-glib problem

Aldrich Niklaus — 2013-05-23T07:40:14

I want to us json-glib to parse a json file ,and I wrote a demo like this.
#include <stdio.h>
#include <stdlib.h>
#include <glib.h>
#include <glib-object.h>
#include <json-glib/json-glib.h>
int main(int argc,char **argv)
    {
        JsonParser *parser;
        GError *error;
        g_type_init();
        parser = json_parser_new();
        json_parser_load_from_file(parser,"info.json",&error);
        if(error)
            {
                g_print("error is %s\n",error->message);
                g_error_free(error);
                g_object_unref(parser);
                return EXIT_FAILURE;
            }
        JsonNode *root;
        root = json_parser_get_root(parser);
        if(JSON_NODE_HOLDS_ARRAY(root))
            {
                puts("hold array\n");
                JsonArray *array;
                array = json_node_get_array(root);
                g_print("the length of the array is
%d\n",json_array_get_length(array));
                root = json_array_get_element(array,0);

The problem of GNOME3 is not the GNOME Shell

bugs — 2013-05-02T20:26:15

Hello!

Please don't take the following explanation as attack on you or your
work. What I want is helping you and GNOME!

The problem of GNOME3 is not the GNOME Shell, it is the constant removal
of features. To make this even more worse, the developers don't
communicate their plans and didn't react on well meant critic. Instead
the developers believe that the bloggers, the press or the users just
hate new things like the GNOME Shell[1].

GNOME 3.0 introduced a complete new user-interface and also some things
did't get ported from GNOME2. This is usual for major change and it is
also ususal that some users have problems with the new user-interface,
while others appreciated it.
The problem is that everyone expected that during the subsequent release
of 3.2, 3.4 and so on the missing parts get added. This happend for
GNOME2 and this happend with KDE4. But it didn't happend for GNOME3!

During the last releases important and loved features and options get
removed from GNOME, instead of added. And GNOME doesn't

The bunch of examples

bugs — 2013-05-02T20:26:25

I will keep this short! Not. I tried but failed! So please pick what
you are interested in. And don't take it personal. I can only apologize
for my own unfair and unpolite behaviour.

// nautilus - create empty file
Every file-browser does manage files, this includes the creation of
"empty files", not only "empty directories". This function was removed
with "3.6". Nautilus doens't fullfill the basic requirement of a
file-browser. This is wrong!
Instead users are forced to use the XDG-Directory "Templates" to create
a template for an empty file. But that is not possible, because for this
you need to create an empty file. This is weird!

Bug reports:
https://bugzilla.gnome.org/show_bug.cgi?id=324253
https://bugzilla.gnome.org/show_bug.cgi?id=676838
https://bugzilla.gnome.org/show_bug.cgi?id=683735
Screenshot:
http://i.imgur.com/CkkOlSL.png
Example:
Create an empty file "main.cpp", which can be double-clicked and edited
within Gedit with propper syntax-hightlighting.
Proposal: "Create empty file" should just b

configure script requires intltool

Simon Kågedal Reimer — 2013-04-20T20:57:04

Hi,

I've written a simple program and based the build setup on the gnome-hello
Git repository [1]. However, when I do a "make dist" and run the configure
script on another computer, I get complaints that intltool is too old, or
that it doesn't exist:

    ./configure: line 11982: intltool-update: command not found
    checking for intltool >= 0.40.0...  found
    configure: error: Your intltool is too old.  You need intltool 0.40.0
or later.

The tarball should including any intltool things that are needed, shouldn't
it?

I get the same result with gnome-hello itself, doing:

    $ git clone git://git.gnome.org/gnome-hello
    $ cd gnome-hello
    $ ./autogen-sh
    $ make
    $ cp /usr/share/gnome-doc-utils/gnome-doc-utils.make .
    $ make dist

Gives me a package that won't build unless I have intltool installed. Is
this how it should be? Seems strange to me, since typically no build tools
like autoconf etc are required on the user computer. I was thinking the
intltool scripts should get bundled when I

Re: Questions about GClosure

Juan Rafael García Blanco — 2013-04-07T19:45:49

Hi,

Thank you Emmanuele, this makes things clearer. I've also read the glib-genmarshal page (https://developer.gnome.org/gobject/stable/glib-genmarshal.html) and I think I've understood this a bit more. 

Then a VOID__VOID callback has the form:
void func (gpointer data1, gpointer data2)

I understand that data2 == user_data (the same user_data passed in cclosure_new). But what is data1? I know that when connecting signals, the first argument of the callback is the object that emitted the signal. This is my question now: what is the parameter that is passed in closure_invoke, and that is different from user_data?

Thank you very much.

Regards,
Juan.

On Apr 7, 2013, at 12:10 PM, Emmanuele Bassi wrote:

Re: Questions about GClosure

Emmanuele Bassi — 2013-04-07T10:10:17

hi;

On Sunday, April 7, 2013, Juan Rafael García Blanco wrote:


you don't pass the user data when calling invoke(). the params[] array
contains only the arguments you specified in the marshaller. the user data
pointer that is then passed to the callback function is the one you used
when creating the GClosure.

a side note: I would not use GClosure, especially if you're concerned about
performance. the GValue boxing and unboxing can become a performance
liability in critical paths. you should use function pointers directly, and
if you need generic arguments, you can resort to varargs. if push come to
shove, using libffi directly is another option at your disposal.

ciao,
 Emmanuele.

Questions about GClosure

Juan Rafael García Blanco — 2013-04-07T09:04:14

Hello everybody,

I've a few questions about how closures should be used. I'm writing a GLib wrapper for OpenCL, and I feel the need to use callbacks. I'll try to explain what I don't understand about closures.

g_cclosure_new takes a pointer to user data as argument. This is passed to the callback in its last argument. But then, when I call g_closure_invoke() I need to pass a GValue array containing the arguments to the callback, and I guess user_data is included here. I see this as a redundant action, so my guess is I've got something wrong. I hope you can clarify this a little bit for me. I'll appreciate it.

Thank you very much in advance.

Regards,
Juan.

Re: GArray conversion

kuldeep dhaka — 2013-04-05T10:48:13

while working on my project,
i again got a problem related to this.

my array count N*2 elements

so i want a natural array of array[N][2] , how can i accomplish this?

i tried to use "nat_array = (type **)g_array_free(garr, FALSE)" but this
time , it cast a 1D array to 2D array, and if accessed the 1D using 2D
method it will (and is) cause segment fault.

generalized description,
if garray contained M*N
then we need an natural array of n_arr[M][N]

description of my project.
it takes input from command line $<program> x,y x,y x,y ....
i dont want it to take input the number of x,y
example: not this --> $<program> N x,y x,y x,y ....

it can be accomplished by reversing the method of storage,
storing x's & y's in different Garray and then dump the g_array_free the
natural pointer to n_arra[2]
im not much interested in implementing this one.

using va_list this can accomplished , which zero as ending, to
g_array_natural.

also, if i accept N , i can solve the problem easily.
i would like to take your opinions

Re: GArray conversion

Christophe Fergeau — 2013-04-04T16:06:38

Hey Kuldeep,

2013/4/4 kuldeep dhaka <kuldeepdhaka9< at >gmail.com>:

I think
natural_array = (gdouble*)g_array_free(arr, FALSE);
would do what you are asking for.

Christophe

GArray conversion

kuldeep dhaka — 2013-04-04T15:08:02

hello guys,
i think a function like this could be useful.

c-code:

GArray * arr;
gdouble * natural_array;
unsigned int size;

arr = g_array_new (FALSE, FALSE, sizeof (gdouble));

... add values to GArray ....

<store the size of garray in size var>

natural_array = g_array_natural(arr, sizeof(double));

#gnome, Juhaz : if you're talking about GArray, the accessor function isn't
a function but macro, so there's no performance penalty to it.

atleast still the function can be useful when we want to make things simple
and when garray functionality is no longer required.

Re: GSOC Idea

Michael Mercier — 2013-03-17T19:15:48

Hello,

I thinks it's a really good idea to improve terminal work with clever and recent tools.
All the points you are giving are relevant. Maybe a field that show physical and memory
location could be added (like http://byobu.co/ do).

I want to notice that I use zsh with the grml config and it does a lot of the things you mention.
It could inspire your project...

Good luck with your project and please keep us in the loop!

Michael
_______________________________________________
gnome-devel-list mailing list
gnome-devel-list< at >gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-devel-list

GSOC Idea

Rajath Shashidhara — 2013-03-15T04:17:13

Hello,


 I aspire to participate in this year's Google Summer of Code. I propose
the idea of making a new intelligent and interactive terminal emulator with
rich GUI features. These are some of the improvements that I propose to
replace the current gnome-terminal:

   1.

         Seperate fields for Input and Output:

 Input and output are clearly seperated from each other in different text
fields.


 2. Flags associated with various terminal commands are shown as a checkbox
group with a brief description about the use of each flag:

   It reduces the effort in finding out the various flags associated with a
               command on man page and then executing the code. When a
command is typed
               the flag list automatically can be pops up a checklist
and recently used
               flags are automatically checked.

 3. Selective copy of recently used commands:

   A recently executed command can be selectively copied.

 e.g.: Previously executed command is:

gcc abc.c -lm -o abc.o

can be se

Name for sanad is merged with the last name value.

Tae Wong — 2013-02-22T05:26:15

Smart quotation marks become question marks with the mail provider,
for example last name’s value becomes last name?s value. You don’t
want your messages automatically rejected; although you’re not working
with GNOME. Read the Foundation Members page in GNOME and check if
sanad is merged with the last name value. You’re not developing for
GNOME.
_______________________________________________
gnome-devel-list mailing list
gnome-devel-list< at >gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-devel-list

Gnome-system-monitor - rounded graphs: a proof of concept

jordan — 2012-12-20T21:32:48

Hi,

Recently, I have been hacking on the gnome-system-monitor code, to
implement some aesthetic changes, for things that have long bothered
me about GSM. the big change that i have been working on - adding
rounded corners to the graphs (rather than having rectangles that
don't even use the same background as the notebook bg color in many
cases (ie: you end up with notebook/graph colors not matching on many
themes + it just looks (imho) a bit ugly / unrefined). So even though
i know very little about cairo (and although, i hack on code from time
to time - wouldn't consider myself to be a 'programmer'), i decided to
see what i could do :) I ended up with decent success, to the point i
would at least think my code produces a good demo/prototype/proof of
concept.

Here is my version of gnome-system-monitor (picture);
http://postimage.org/image/c1k6h723d/

and a quick video, just showing the resizing working correctly;
http://www.youtube.com/watch?v=QgeAeCayw7Q

NOTE: pay no attention to the hardcoded backgroun

Re: glib gio usage of the library outside of GNOME

Alexander Larsson — 2012-11-02T09:05:21

On ons, 2012-10-24 at 18:41 +0200, Michael Weimann wrote:

Inside gio there is a default implementation of GVolumeMonitor that is
very much a "traditional unix" style thing. It only looks at /etc/mtab
and /etc/fstab and does some magic matching to guess what is what. This
is clearly not going to get you everything that a "modern" desktop
needs. For instance, there is no concept of a "drive" in such a setup
(for unix, an entry in mtab is a mount, and an entry in fstab is a
volume), nor do we know much about the properties of the volumes.

In order to get more information from the volume monitior you need:

a) gvfs installed, with at least one native volume monitor
implementation (and its dependencies) built. We currently ship a hal
one, a gnome-disk-utils one and a udisk2 one.
b) A session dbus running. This is on by default in an X session, but
you can launch your own with dbus-launch in a terminal if you want.

Re: Coordination between developers in the GNOME project

David Gomes — 2012-11-01T20:54:24

This is the most active mailing list, but don't forget to check on IRC
because I believe there are more developers there.

On Thu, Nov 1, 2012 at 8:53 PM, Tengy Td <duret.tanguy< at >gmail.com> wrote:

Re: Coordination between developers in the GNOME project

David Gomes — 2012-11-01T20:49:40

Many Gnome developers are under the age of 18, why not allow such ages?

Also, for some reason I think this mailing list isn't very active.

On Thu, Nov 1, 2012 at 8:39 PM, Tengy Td <duret.tanguy< at >gmail.com> wrote:

Coordination between developers in the GNOME project

Tengy Td — 2012-11-01T20:39:25

Hello,


I am a French student and I am currently realizing my final thesis in the
field of Free/libre open source software.

It would be a great help for me if you could answer a short online survey
(it should take approximately 5 minutes).

 This survey is designed to reach a better understanding of the cooperation
and coordination between developers in Free/libre open source projects.

There is no right or wrong answers, therefore, feel free to answer
spontaneously and to skip the questions you feel you do not want to answer.

The link to the survey is: http://bit.ly/U1BjTh


I would like to remind you that the participation is absolutely anonymous
and voluntary, and you can quit it at any time. Your answers will be
strictly confidential and will be used only for research purpose (no
commercial use of any information you provided).



If you find this survey interesting, you are welcome to share it with other
developers!


If you want to add something, or if you need further information about this
survey

Re: How to prevent gnome-settings-daemon from touching keyboardconfiguration at all?

Chow Loong Jin — 2012-10-31T13:21:38

On 31/10/2012 20:27, Vasily Khoruzhick wrote:

It's a per-user setting. As for removing the keyboard plugin, that's also quite
possible without recompiling -- just remove
/usr/lib/gnome-settings-daemon-3.0/libkeyboard.so and
/usr/lib/gnome-settings-daemon-3.0/keyboard.gnome-settings-plugin.


P.S. Please don't send me a direct mail when you reply -- I read this list
through gmane.