Gtk+3 application Internationalization
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
Re: argv
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", &argv[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
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: Gtk+3 application Internationalization
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
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
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
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
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[2]: argv
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", &argv[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+ newb: Some basic infos
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
GtkColorChooser questions
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