Re: Abuse of 'const' ?

[John Emmas]

On 08/04/2013 14:09, Ryan Lortie wrote:


A 'const gchar **' is (in this case) an array of 'const gchar *' (ie: 
const string pointers).  It is the strings that are immutable.  The 
array itself is fully writable, and indeed you should free what 
g_variant_get_bytestring_array() returns to you, using g_free().




Good clarification Ryan.  Thanks!
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Abuse of 'const' ?

[Ryan Lortie]

hi John,

On 2013-04-08 04:44, John Emmas wrote:

// glib/gvariant.h
GLIB_AVAILABLE_IN_ALL
const gchar **g_variant_get_bytestring_array (GVariant *value, gsize
*length);


// glib/gvariant.c
static gpointer
g_variant_valist_get_nnp (const gchar **str, GVariant *value)
{
 // some stuff
 return g_variant_get_bytestring_array (value, NULL);
}



A 'const gchar **' is (in this case) an array of 'const gchar *' (ie: 
const string pointers).  It is the strings that are immutable.  The 
array itself is fully writable, and indeed you should free what 
g_variant_get_bytestring_array() returns to you, using g_free().


By the same token it is therefore perfectly acceptable to pass it 
through a gpointer.


Cheers
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkAppChooser custom command patch

[tarnyko]

Matthias, 

Would it be possible to have it Nautilus, then ? 

But not as an additional package or script. In vanilla Nautilus (= vanilla 
GNOME). 

Because that's all my users are asking for. 


Regards,
Matthias 

Matthias Clasen writes: 


On Mon, Apr 8, 2013 at 7:48 AM, Bernhard Schuster
 wrote:

There will always be the case that some application will not do it properly.
Instead of annoying the end-user, give him/her the option to fix it
him/herself. It is not that it would hurt, it's rather a salvation for the
daily highcups and struggle with beta/commercial applications.


But selecting 'custom command' doesn't fix it in any way. Fixing it
would involved editing the desktop file, adding the necessary mime
type, and sending a patch to the application author. 


I don't doubt that 'custom command' functionality is useful. But I
don't think it should live in the app chooser dialog.

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

Re: GtkAppChooser custom command patch

[tarnyko]

Andreas, 

If it could be an *integrated* Nautilus feature, that would be great. 

Actually, it's all my users are asking for. Having the ability to run 
"custom command" in Nautilus. 

But it should *not* be an additional package -which you might not have 
installed on some systems - but definitely an integrated one. Should come 
with vanilla GNOME. 

I didn't hack Nautilus because I didn't know anything about it, and am more 
a GTK+ guy. 


Regards,
Tarnyko 

Andreas Tunek writes: 


Where do you think it should live? In a nautilus extension ("Open with
custom" or something)? 

/Andreas 



2013/4/8 Matthias Clasen  


On Mon, Apr 8, 2013 at 7:48 AM, Bernhard Schuster
 wrote:
> There will always be the case that some application will not do it
properly.
> Instead of annoying the end-user, give him/her the option to fix it
> him/herself. It is not that it would hurt, it's rather a salvation for
the
> daily highcups and struggle with beta/commercial applications. 


But selecting 'custom command' doesn't fix it in any way. Fixing it
would involved editing the desktop file, adding the necessary mime
type, and sending a patch to the application author. 


I don't doubt that 'custom command' functionality is useful. But I
don't think it should live in the app chooser dialog.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list 


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

Re: Composite GtkBuilder template

[Tristan Van Berkom]

On Mon, 2013-04-08 at 07:30 -0400, Matthias Clasen wrote:
> > Are we about ready to move forward with this ?
> 
> The color editor still has a round knob, where it didn't use to.
> That's the only thing I still notice being different.

I have just pushed a fix for this.

I was unable to really reproduce the problem, as my knobs show up
square and there is no easy way to load a specific .css (that I know
of).

But stepping through GtkWidget's buildable implementation showed that
the 

Fwd: GtkAppChooser custom command patch

[Andreas Tunek]

Where do you think it should live? In a nautilus extension ("Open with
custom" or something)?

/Andreas


2013/4/8 Matthias Clasen 

> On Mon, Apr 8, 2013 at 7:48 AM, Bernhard Schuster
>  wrote:
> > There will always be the case that some application will not do it
> properly.
> > Instead of annoying the end-user, give him/her the option to fix it
> > him/herself. It is not that it would hurt, it's rather a salvation for
> the
> > daily highcups and struggle with beta/commercial applications.
>
> But selecting 'custom command' doesn't fix it in any way. Fixing it
> would involved editing the desktop file, adding the necessary mime
> type, and sending a patch to the application author.
>
> I don't doubt that 'custom command' functionality is useful. But I
> don't think it should live in the app chooser dialog.
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Composite GtkBuilder template

[Benjamin Otte]

Yes, I've perfected the API with Tristan for a while and I'm happy
with it. From our last discussion the things we were waiting on were:

- Ryan's construct properties work
I think the conclusion here was to merge anyway and adapt gtk once the
glib work lands.
- The intltool issue
No idea, that was yours and Tristan's territory, I'm happy not to be
involved in build issues.

Other than that, I think it's ready to merge and let early adopters go
and find bugs.

Benjamin


On Mon, Apr 8, 2013 at 1:30 PM, Matthias Clasen
 wrote:
>> Are we about ready to move forward with this ?
>
> The color editor still has a round knob, where it didn't use to.
> That's the only thing I still notice being different.
>
> I haven't looked at the added api in detail, but I think Benjamin had
> reviewed and ok'ed that already ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkAppChooser custom command patch

[Matthias Clasen]

On Mon, Apr 8, 2013 at 7:48 AM, Bernhard Schuster
 wrote:
> There will always be the case that some application will not do it properly.
> Instead of annoying the end-user, give him/her the option to fix it
> him/herself. It is not that it would hurt, it's rather a salvation for the
> daily highcups and struggle with beta/commercial applications.

But selecting 'custom command' doesn't fix it in any way. Fixing it
would involved editing the desktop file, adding the necessary mime
type, and sending a patch to the application author.

I don't doubt that 'custom command' functionality is useful. But I
don't think it should live in the app chooser dialog.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkAppChooser custom command patch

[tarnyko]

Hi Matthias, 

It was that kind of answer that I was asking for. 

So what you're telling me is that I shouldn't try to develop the patch any 
further, because it will never be integrated upstream, right ? 

If that's the case, I will come back to my user group with this answer. 

I think you (not personally, but taken more widely) are wrong, and that it 
does some harm here, but fair enough, it is definitely your project. 

I won't debate this again, points have already been widely made before 
(Bernhard does have some here). Personally, what I regret the most is having 
spent time writing a useless patch. It does imply something for my past and 
future-planned contributions, too. 


Regards,
Tarnyko 

Matthias Clasen writes: 


I don't think we want that in the app chooser, I'm afraid.
Applications need to be installed properly, which will make them show
up in the list of application.  Turning the app chooser into a
fix-up-your-os tool is not the right answer. 


On Mon, Apr 8, 2013 at 7:13 AM,   wrote:

Thank you Bernard !
I've written the change due to recurring requests from my local user group
(and other people, too).
Any feedback is welcome.
Regards,
Tarnyko
Bernhard Schuster writes:


I did not look at your implementation, but the screenshots look very
promising - in fact I think that is a highly desirable feature and your
implementation is (imho) how it should be done! 



2013/4/8 


Hi folks,
Could someone please review the following patch/suggestion : 

https://bugzilla.gnome.org/**show_bug.cgi?id=650284#c36 


It adds a "Use custom command" on the lower part of the GtkAppChooser
window, so users can specify an unlisted application (case of uncomplete
mimetypes or .desktop associations).
Screenshots are available in the comment.
The patch itself is unfinished, I'm mostly asking for feedback about the
general idea and design.
Regards,
Tarnyko
__**_
gtk-devel-list mailing list
gtk-devel-list@gnome.org 


https://mail.gnome.org/**mailman/listinfo/gtk-devel-**list


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

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

Re: GtkAppChooser custom command patch

[Matthias Clasen]

I don't think we want that in the app chooser, I'm afraid.
Applications need to be installed properly, which will make them show
up in the list of application.  Turning the app chooser into a
fix-up-your-os tool is not the right answer.

On Mon, Apr 8, 2013 at 7:13 AM,   wrote:
> Thank you Bernard !
> I've written the change due to recurring requests from my local user group
> (and other people, too).
> Any feedback is welcome.
> Regards,
> Tarnyko
> Bernhard Schuster writes:
>>
>> I did not look at your implementation, but the screenshots look very
>> promising - in fact I think that is a highly desirable feature and your
>> implementation is (imho) how it should be done!
>>
>>
>> 2013/4/8 
>>>
>>> Hi folks,
>>> Could someone please review the following patch/suggestion :
>>>
>>> https://bugzilla.gnome.org/**show_bug.cgi?id=650284#c36
>>>
>>> It adds a "Use custom command" on the lower part of the GtkAppChooser
>>> window, so users can specify an unlisted application (case of uncomplete
>>> mimetypes or .desktop associations).
>>> Screenshots are available in the comment.
>>> The patch itself is unfinished, I'm mostly asking for feedback about the
>>> general idea and design.
>>> Regards,
>>> Tarnyko
>>> __**_
>>> gtk-devel-list mailing list
>>> gtk-devel-list@gnome.org
>>>
>>> https://mail.gnome.org/**mailman/listinfo/gtk-devel-**list
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Composite GtkBuilder template

[Matthias Clasen]

> Are we about ready to move forward with this ?

The color editor still has a round knob, where it didn't use to.
That's the only thing I still notice being different.

I haven't looked at the added api in detail, but I think Benjamin had
reviewed and ok'ed that already ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkAppChooser custom command patch

[tarnyko]

Thank you Bernard ! 

I've written the change due to recurring requests from my local user group 
(and other people, too).
Any feedback is welcome. 


Regards,
Tarnyko 

Bernhard Schuster writes: 


I did not look at your implementation, but the screenshots look very
promising - in fact I think that is a highly desirable feature and your
implementation is (imho) how it should be done! 

 



2013/4/8  


Hi folks,
Could someone please review the following patch/suggestion :
https://bugzilla.gnome.org/**show_bug.cgi?id=650284#c36
It adds a "Use custom command" on the lower part of the GtkAppChooser
window, so users can specify an unlisted application (case of uncomplete
mimetypes or .desktop associations).
Screenshots are available in the comment.
The patch itself is unfinished, I'm mostly asking for feedback about the
general idea and design.
Regards,
Tarnyko
__**_
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/**mailman/listinfo/gtk-devel-**list 


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

GtkAppChooser custom command patch

[tarnyko]

Hi folks, 

Could someone please review the following patch/suggestion : 

https://bugzilla.gnome.org/show_bug.cgi?id=650284#c36 

It adds a "Use custom command" on the lower part of the GtkAppChooser 
window, so users can specify an unlisted application (case of uncomplete 
mimetypes or .desktop associations). 

Screenshots are available in the comment. 

The patch itself is unfinished, I'm mostly asking for feedback about the 
general idea and design. 


Regards,
Tarnyko
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Composite GtkBuilder template

[Tristan Van Berkom]

On Sun, 2013-04-07 at 23:50 -0400, Matthias Clasen wrote:
> > I guess it's time for me to drop this for the day, I just dont
> > know if I can afford to spend time on it tomorrow, looks like
> > I'll be spending some long nights after hours on this...
> 
> Here is a patch that seems to work ok.

Mathias,
   Thanks a lot for taking time to and writing code towards
addressing the i18n issues without intltool.

I've taken the following actions on the branch:

  o Removed the initial INTLTOOL commit so it's not in the history

  o Edited all the commits which port widgets to use templates,
to NOT modify POTFILES.in at all (so the base work compiles
but is not translatable).

  o Applied your patch, with some modifications, at the HEAD of the
branch, with the additions of all the .ui.h entries in POTFILES.in

(the modifications I made was just to ensure that the .ui.h files
actually get generated, by adding them as a dependency to the
gtkresources.c build).

This way, the branch compiles at any given commit in the history, and
the last patch addresses the i18n issues.

I've also tested it, by adding some random translatable text into a .ui
file, building, running "make -C po/ update-po" and grepping for my new
translatable text.

This is working well.

Are we about ready to move forward with this ?

Cheers,
-Tristan


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

Abuse of 'const' ?

[John Emmas]

Occasionally, I've noticed a couple of things like this when building Glib:-

// glib/gvariant.h
GLIB_AVAILABLE_IN_ALL
const gchar **g_variant_get_bytestring_array (GVariant *value, gsize 
*length);



// glib/gvariant.c
static gpointer
g_variant_valist_get_nnp (const gchar **str, GVariant *value)
{
// some stuff
return g_variant_get_bytestring_array (value, NULL);
}

This has the effect of converting const** into non-const gpointer. Is it 
worth reporting this kind of thing in bugzilla?


John
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list