GtkColorChooser questions

[rbd]

Hi all,

I am trying to use the GtkColorChooserDialog (3.14 under CentOS7 and also 
3.18 under MacOS/MacPorts) and have two questions:


(1) My app will potentially do a substantial amount of custom color 
creation. Every time I make a new custom color with GtkColorChooserDialog, 
the next time I open the dialog to make another custom color, my previous 
custom color gets added as a new color swatch to the right of the custom 
color button at the bottom of the dialog. This ultimately leads to a LOT 
of unwanted color swatches in the dialog. It gets even worse as it seems 
that these custom colors are remembered when I exit the program and 
restart. I do NOT want to see every custom color I have created since the 
beginning of time appear as its own swatch in this custom color display! 
How do I disable this behavior so that I NEVER see new custom color 
swatches displayed in the dialog? I have tried calling 
gtk_color_chooser_add_palette() but that seems to only get rid of the 
row/column standard swatch display, while leaving all the unwanted custom 
color swatches in place. I have found that 'gsettings reset 
org.gtk.Settings.ColorChooser custom-colors' will clear the custom color 
swatches between program runs, but (i) that's a solution beyond the 
expertise of many of my users, and (ii) I want this unwanted swatch 
proliferation within each program execution to stop as well.


(2) Running the GtkColorChooserDialog via gtk_dialog_run() seems to always 
result in a two-step operation for the user. First, a palette of swatches 
is displayed. Then, if the user clicks the custom button (or asks to 
customize an existing color), the HSV color field tool displays and can be 
used to create a new color. I find the whole palette swatch display step a 
waste of time -- what I really want to do is to go straight to the HSV 
color field selector after first initializing the color field, via program 
subroutine call and not user GUI activity, to an initial arbitrary RGB 
setting. Is there a way to do this?


I have only tried the GtkColorChooserDialog so far, and not the 
GtkColorButton or GtkColorChooserWidget, as I saw nothing in their 
documentation that hinted I would get better results by using either of 
them directly instead of the GtkColorChooserDialog. If I'm mistaken please 
advise! (All things being equal I'd prefer using the dialog for 
programmatic convenience.)


Any suggestions (other than write my own color chooser, which I fear may 
be my ultimate fate)?


Roger Davis
Univ. of Hawaii

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

Gtk+ newb: Some basic infos

[Peter Wiehe]

Hello,

I want to program C++ applications with a GUI, but I am new to Gtk+ and gtkmm 
programming.


1.) What are the really important differences between Gtk+ 2 and 3?

2.) Can you recommend a really good paper book? (There seem to be a ton of Gtk+ 
2 books but not a single one about Gtk+ 3.)




Kind regards and happy coding

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

Re[2]: argv

[Andrew Robinson]

Hi John,

The C code for main(int argc, char *argv[]) is standardized and can only mean
one thing on a 32-bit version of any program: argc is an immediate value of 4
bytes length and argv is a 4-byte pointer to an array of 32-pointers to
zero-terminated strings. Then when main is called, it will first push the
32-bit argv integer value, then push a 32-bit argc pointer, then push the
32-bit return address. So the offsets are correct, i.e. -- [ebp-0] = return
address of callee, [ebp-4] = int argc, and [ebp-8] = *argv.

So debugging this is easy: look at the first three 32-bit items on the stack
at the entry point of main(), and look for an integer value of 4 (because I
have three test parameters on the command line that I am passing) on the
stack. But it does not exist *anywhere* on the stack, even 20 or 30 items
down. But then the API documentation for GTK+ says that argc is not an int,
but a pointer to an int (int *argc and char ***argv). So if I presume
everything on the stack is a pointer, I still cannot find the integer value of
4. The closest I have come is a value of 2, which is still wrong. I don't know
if I mentioned this, but *every* value on the stack points to nonsense
(meaning "not the command line or it's address"), no matter how far you
recurse into it. The address where the command line string is contained is not
even close to being referenced by anything on the stack. It's interesting that
my debugger can automatically find the command line but GTK+ cannot.

Therefore it would make sense that the code you have posted below does not
work due to the above mentioned observations, although according to the
documentation it seems as though it should ... unless the API documentation is
wrong or my 32-bit GTK+ runtimes I got from the GtkD project are corrupted
with bad source code or that GtkD used a compiler parameter that restricts the
runtimes to processing of the GUI only. So I did a little research and
discovered that there is a function for getting the command line in GTK+:

g_application_new(G_APPLICATION_HANDLES_COMMAND_LINE)

which used in conjunction with g_signal_connect() and G_CALLBACK, passes it
off to a function where you can use the code like you posted below, with the
usual expected results. Why have this function though, if a simple direct
routine like you posted below would work? It would be overkill, but I am going
to try using this method and if it works, it would prove that the GTK+ API
documentation is incorrect, that argc and argv are not pointers or values, but
handles -- at least in the 32-bit version of GTK+ for Windows. This would
explain why I can't make it work in GTK+ v3.18 or why the code posted below
doesn't work.

Andrew

On 4/14/2016 at 8:03 AM, John Coppens  wrote:
>On Sat, 9 Apr 2016 18:39:49 -0700
>"Andrew Robinson"  wrote:
>
>> The problem is that [ebp + 12] and [ebp + 8] point to nonsense. I ran a
>> debugger and looked at the stack, and there is nothing else on the stack
>> except for ebp, rtn addr, and these two parameters. I even tried
>> daisy-chaining the addresses to see where they would lead, and they are not
>> even close to pointing to the actual command line. I can easily find the
>> command line using a memory search, so I know what address it should be.
What
>> am I doing wrong here? I have:
>
>Never done this, and I don't have Windows, so I don't know if this is useful.
>
>- The command line you found may not be the same as is passed to main().
>Recall that that argv is an array of strings, not pointers to the actual
>command line.
>
>- This program shows the addresses of the individual args:
>
>#include
  
>   
>int
>main(int argc, char *argv[]) {
>  int i;
>
>  for (i = 0; i < argc; i++) {
>printf("%p: %s\n", [i], argv[i]);
>  }
>
>  return 0;
>}
>
>~$ ./args a b c d
>0x7ffd48ffc538: ./args
>0x7ffd48ffc540: a
>0x7ffd48ffc548: b
>0x7ffd48ffc550: c
>0x7ffd48ffc558: d
>
>As you can see, the addresses are aligned to 8 byte levels, as this is a
>64-bit computer. Your offsets could be wrong, as they depend on the
>word length of the computer.
>
>John

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

Re: Gtk+3 application Internationalization

[Emmanuele Bassi]

Hi;

On 14 April 2016 at 17:09, Dave Howorth  wrote:

>>> I don't know, if I understand it well, that I must translate all
>>> strings in my application (copy from Stock Items) one more time to all
>>> languages just like Gtk if I want to use them ?
>>
>>
>> It's hardly going to be an issue.
>
>
> I don't understand. With the old method, I chose stock items and
> localisation was done automatically by the system, yes? As application
> author I didn't have to consider it.

It's not "done by the system": GTK carries the translations under its
own gettext domain.

> How is localisation done in the new system?

In the same way you localize your application's strings — either using
gettext, or using any other tool that lets you load translated strings
given an identifier.

These are the developer guidelines and tools used by the GNOME project:

  https://wiki.gnome.org/TranslationProject/DevGuidelines

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Gtk+3 application Internationalization

[Dave Howorth]

On 2016-04-14 16:27, Emmanuele Bassi wrote:

On 14 April 2016 at 08:30, Ondrej Tuma  wrote:


because Stock Items are deprecated from Gtk+3.10, what can I use, if I
want to use gtk locales in my Application.


Use your own (localized) string.

Better yet, use readable strings that rely on the context of the
operation, instead of just random words that the tool kit itself has
no way to adapt to your case.


I don't know, if I understand it well, that I must translate all
strings in my application (copy from Stock Items) one more time to all
languages just like Gtk if I want to use them ?


It's hardly going to be an issue.


I don't understand. With the old method, I chose stock items and 
localisation was done automatically by the system, yes? As application 
author I didn't have to consider it.


How is localisation done in the new system? I've looked at

https://docs.google.com/document/d/1KCVPoYQBqMbDP11tHPpjW6uaEHrvLUmcDPqKAppCY8o/pub

but I'm afraid I still don't understand.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Gtk+3 application Internationalization

[Emmanuele Bassi]

Hi;

On 14 April 2016 at 16:58, Murray Cumming  wrote:
> On Thu, 2016-04-14 at 16:27 +0100, Emmanuele Bassi wrote:
>> > I don't know, if I understand it well, that I must translate all
>> > strings in my application (copy from Stock Items) one more time to
>> all
>> > languages just like Gtk if I want to use them ?
>>
>> It's hardly going to be an issue.
> [snip]
>
> There are some strings such as Cancel, Close, Quit, File, Edit, Cut,
> Copy, Paste that really should be the same in each application.

Except that those come with a mnemonic as well, and that's the issue.

Again, if somebody is translating "File" for a menu bar, adding a
string to applications is not going to be a problem for any
translator.

> The lack of (useful) stock items makes it harder to make them the same
> in each application. It's a genuine concern.

They don't always *need* to be the same; and if they need to be the
same, then it should be up to the platform guidelines to specify them.
The tool kit is not in the position of enforcing that on every
platform, for every application, in every possible locale.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Gtk+3 application Internationalization

[Murray Cumming]

On Thu, 2016-04-14 at 16:27 +0100, Emmanuele Bassi wrote:
> > I don't know, if I understand it well, that I must translate all
> > strings in my application (copy from Stock Items) one more time to
> all
> > languages just like Gtk if I want to use them ?
> 
> It's hardly going to be an issue.
[snip]

There are some strings such as Cancel, Close, Quit, File, Edit, Cut,
Copy, Paste that really should be the same in each application.

The lack of (useful) stock items makes it harder to make them the same
in each application. It's a genuine concern.

I'm not bothered by the lack of things like OK, Yes, and No, which
shouldn't be used anyway.

-- 
Murray Cumming
murr...@murrayc.com
www.murrayc.com



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

Re: Gtk+3 application Internationalization

[Emmanuele Bassi]

Hi;

On 14 April 2016 at 08:30, Ondrej Tuma  wrote:

> because Stock Items are deprecated from Gtk+3.10, what can I use, if I
> want to use gtk locales in my Application.

Use your own (localized) string.

Better yet, use readable strings that rely on the context of the
operation, instead of just random words that the tool kit itself has
no way to adapt to your case.

> I don't know, if I understand it well, that I must translate all
> strings in my application (copy from Stock Items) one more time to all
> languages just like Gtk if I want to use them ?

It's hardly going to be an issue.

> Where is benefits of this, sorry, stupid decision.

Why do you apologize while simultaneously insulting the judgement of
the people that maintain this project, then? You could have avoided
saying "stupid" and it would have been fine.

> When i use Stock
> Items, i have my application base translated to all languages which Gtk
> have. How can i do that without Stock Items ? I hope, that I had missed
> something. Please tell me what.

You missed the fact that the tool kit cannot write anything more
complicated that simple words, and that it cannot handle conflicts of
mnemonics for you in multiple languages. If you use the stock string
for "_Save" and you have another UI element for "_Suspend", GTK cannot
know which mnemonic is going to be the right one when you press Alt+S;
now expand that potential for collisions to all languages and all
strings. It's untenable, and unmaintainable, and one of the reasons
why stock strings were deprecated.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Gtk+3 application Internationalization

[John Coppens]

On Thu, 14 Apr 2016 09:30:10 +0200
Ondrej Tuma  wrote:

> Where is benefits of this, sorry, stupid decision. When i use Stock
> Items, i have my application base translated to all languages which Gtk
> have. How can i do that without Stock Items ? I hope, that I had missed
> something. Please tell me what.

I might be wrong, but there are still standard items (they're not
called Stock Items anymore). They're not called by their Stock name,
but still get translated automatically. They are not in a box called
Stock Items, but instead come from Icon Themes:

This is the old and new way compared:

Old:
button = gtk_button_new_from_stock (GTK_STOCK_SAVE);

New:
button = gtk_button_new_with_mnemonic (_(“_Save”));

Have a look at the announcement of the 'new' way:

https://docs.google.com/document/d/1KCVPoYQBqMbDP11tHPpjW6uaEHrvLUmcDPqKAppCY8o/pub

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

Re: argv

[John Coppens]

On Sat, 9 Apr 2016 18:39:49 -0700
"Andrew Robinson"  wrote:

> The problem is that [ebp + 12] and [ebp + 8] point to nonsense. I ran a
> debugger and looked at the stack, and there is nothing else on the stack
> except for ebp, rtn addr, and these two parameters. I even tried
> daisy-chaining the addresses to see where they would lead, and they are not
> even close to pointing to the actual command line. I can easily find the
> command line using a memory search, so I know what address it should be. What
> am I doing wrong here? I have:

Never done this, and I don't have Windows, so I don't know if this is useful.

- The command line you found may not be the same as is passed to main().
Recall that that argv is an array of strings, not pointers to the actual
command line.

- This program shows the addresses of the individual args:

#include   

   
int
main(int argc, char *argv[]) {
  int i;

  for (i = 0; i < argc; i++) {
printf("%p: %s\n", [i], argv[i]);
  }

  return 0;
}

~$ ./args a b c d
0x7ffd48ffc538: ./args
0x7ffd48ffc540: a
0x7ffd48ffc548: b
0x7ffd48ffc550: c
0x7ffd48ffc558: d

As you can see, the addresses are aligned to 8 byte levels, as this is a
64-bit computer. Your offsets could be wrong, as they depend on the
word length of the computer.

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

Gtk+3 application Internationalization

[Ondrej Tuma]

Hi,

because Stock Items are deprecated from Gtk+3.10, what can I use, if I
want to use gtk locales in my Application.

I don't know, if I understand it well, that I must translate all
strings in my application (copy from Stock Items) one more time to all
languages just like Gtk if I want to use them ?

Where is benefits of this, sorry, stupid decision. When i use Stock
Items, i have my application base translated to all languages which Gtk
have. How can i do that without Stock Items ? I hope, that I had missed
something. Please tell me what.

Thanks a lot

-- 
Ondřej Tůma 
www: http://ipv6.mcbig.cz   jabber: mc...@jabber.cz   twitter: mcbig_cz
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list