Re: Pause and resume GtkApplication

[Alexander Koeppe]

Hi

just FYI: I solved it.

The trick was that within the second g_application_run(), the app menu
must be attached to the application using gtk_application_set_app_menu()
*before* adding the already existing _window_ using
gtk_application_add_window() to the application.

This way the app-menu is properly (or still) shown in the same window
throughout both GtkApplication instances.

Regards
   - Alex

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

Re: Pause and resume GtkApplication

[Alexander Koeppe]

Thanks to all of you.

I try to incorporate all the advisories and hints as best as I can given
the constraints underlying.


Cheers


 -- Alex

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

Re: Pause and resume GtkApplication

[Chris Vine]

On Fri, 26 Jan 2018 11:14:36 +0700
"Lucky B.C" <lblack...@gmail.com> wrote:
> Well, in the case, I will tell something about me, first I've never
> used the GtkApplication just main window maybe sub windows (dialogs)
> too, and my programs did not do as what you are trying to do. Second
> I'm a C programmer, in my opinion, you should redesign your app
> because sometimes we must do that to gain our main target not about
> GUI which we only need for rendering/displaying to the user. Nothing
> is perfect! If we don't want the user see the private data or
> something else, we just don't show it by doing in another thread.
> Yes, the main loop of GTK always runs after we called gtk_main (),
> but we can create another thread before gtk_init () is called and run
> it anytime we need by gdk_threads_enter and gdk_threads_leave, for
> more detail see GThreads
> <https://developer.gnome.org/glib/stable/glib-Threads.html#g-thread-new>
> and IDLES
> <https://developer.gnome.org/gdk2/stable/gdk2-Threads.html>. Finally
> just reload/refresh our new data/thing again to the user or show a
> message dialog says somthing else, for example "Your data changed!".
> I wonder is there some programs which have the same what you are
> trying to do? If there's one or more, please send me the link, I
> really want to test them.

gdk_threads_enter and gdk_threads_leave are absolutely not the way to
do it.  They are deprecated in GTK+3 and will be removed in GTK+4.
Furthermore they only work with the X backend (not with windows or
wayland) and are horribly error-prone.

The correct way for a worker thread to pass back a result to the glib
main loop, or to execute code in that loop, is for it to post an event
using g_idle_add() and cognates.  The glib main loop is thread safe.

gdk_threads_add_idle is only necessary if your code interfaces with
ancient third-party library code which uses gdk_threads_enter and
gdk_threads_leave.  The best thing to do with such ancient libraries is
not to use them.

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

Re: Pause and resume GtkApplication

[Lucky B.C]

Well, in the case, I will tell something about me, first I've never used
the GtkApplication just main window maybe sub windows (dialogs) too, and my
programs did not do as what you are trying to do. Second I'm a C
programmer, in my opinion, you should redesign your app because sometimes
we must do that to gain our main target not about GUI which we only need
for rendering/displaying to the user. Nothing is perfect! If we don't want
the user see the private data or something else, we just don't show it by
doing in another thread. Yes, the main loop of GTK always runs after we
called gtk_main (), but we can create another thread before gtk_init () is
called and run it anytime we need by gdk_threads_enter and
gdk_threads_leave, for more detail see GThreads
<https://developer.gnome.org/glib/stable/glib-Threads.html#g-thread-new>
and IDLES <https://developer.gnome.org/gdk2/stable/gdk2-Threads.html>.
Finally just reload/refresh our new data/thing again to the user or show a
message dialog says somthing else, for example "Your data changed!". I
wonder is there some programs which have the same what you are trying to
do? If there's one or more, please send me the link, I really want to test
them.

On Fri, Jan 26, 2018 at 5:10 AM, Alexander Koeppe <alexander@koeppe.rocks>
wrote:

> Thanks Lucky,
>
> Good idea to create the widget right away and hide it until it's time.
>
> However, just by accident, I got back the app-menu in the window.
>
> Try this with the code below:
>
> 1. After I selected "Restart" simulating the pause and resume, the
> app-menu disappeared.
> 2. Then I double-clicked the header-bar to maximise the window and the
> app-menu reappeared.
> 3. Again double-clicked the header-bar to restore the original geometry
> the app-menu is still there.
>
> This is what I want. Question is, what happens when I double click the
> header-bar and can I emulate this event in code?
>
> I feel being just 1 grain off my goal
>
> Thanks
>
>-Alex
>
>
> Am 23.01.2018 um 22:37 schrieb Lucky B.C:
> > Wow, I see your problem is that you did not understand what GtkBuilder
> > and Gtk are doing, Because If I'm not wrong, each choice (entry) is a
> > function to start something you want to do after the user/you clicked
> > to the button called "restart". Here's my solution, it's maybe help
> > you.
> >
> > *) You can use gtk_widget_hide (target) function to hide any widget,
> > in this case it's the main window. Then you can do your low-level
> > functions what the other can see at the time after the signal
> > "clicked" activated.
> >
> > Note: Some programs I saw the program did not exit when it's called to
> > restart, there's only the changed/related data must be reload to
> > buffer/ram, and the program must stop rendering/running at the time,
> > after the reloading's done the program continues to render/display the
> > new data in the screen. The reloading can be done in a new thread too,
> > after used you can delete it too.
> >
> > On Wed, Jan 24, 2018 at 2:52 AM, Alexander Koeppe
> > <alexander@koeppe.rocks> wrote:
> >> I know about the possiblity to fire the low-level functions using an
> button
> >> callback. However this would draw an exception for other UI choices the
> >> application has: e.g. text, deamon.
> >>
> >> Therefore I'm looking for a way to keep the application structure for
> all
> >> UIs the same.
> >>
> >> There is the test app I'm playing with:
> >>
> >>
> >> #include 
> >>
> >> GtkApplication *app;
> >> GtkWidget *window;
> >> int initialized = 0;
> >>
> >> void quit_cb(GSimpleAction *action, GVariant *value, gpointer data)
> >> {
> >>g_print("quit!\n");
> >>g_object_unref(app);
> >>exit(0);
> >> }
> >>
> >> void restart_cb(GSimpleAction *action, GVariant *value, gpointer data)
> >> {
> >>g_print("restart!\n");
> >>g_application_quit(G_APPLICATION(app));
> >> }
> >>
> >> void test_cb(GSimpleAction *action, GVariant *value, gpointer data)
> >> {
> >>   GtkWidget *dialog;
> >>   GtkDialogFlags flags = GTK_DIALOG_DESTROY_WITH_PARENT;
> >>
> >>
> >>   dialog = gtk_message_dialog_new(GTK_WINDOW(window),
> >>   flags,
> >>   GTK_MESSAGE_ERROR,
> >>   GTK_BUTTONS_CLOSE,
> >>   "TEst Message");
>

Re: Pause and resume GtkApplication

[Joël Krähemann]

Well, do a context menu and forget about it. In opensuse it is a
special package you install for Gnome3 :/

On Fri, Jan 26, 2018 at 12:30 AM, Alexander Koeppe
 wrote:
> It's not really because of async execution.
> I just tried various gtk_window functions that trigger the
> "window-state-change" event. But not all of them provide the desired effect.
> e.g.
> gtk_window_maximize() reappears the app-menu.
> gtk_window_iconfify() not
>
> So I wonder what is the default callback function of that signal which
> in case of maximization does a little thing that brings back the
> app-menu to my window.
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Pause and resume GtkApplication

[Alexander Koeppe]

It's not really because of async execution.
I just tried various gtk_window functions that trigger the
"window-state-change" event. But not all of them provide the desired effect.
e.g.
gtk_window_maximize() reappears the app-menu.
gtk_window_iconfify() not

So I wonder what is the default callback function of that signal which
in case of maximization does a little thing that brings back the
app-menu to my window.

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

Re: Pause and resume GtkApplication

[Joël Krähemann]

Hi

Just some explanation. Your timeout is is dispatched by gtk_main(). As
doing your call to the backend,
you have to listen on message and then forward the event to the UI.

AgsAudio::set-pads() actually is part of my backend. Sends the message.

Here you need some async non-blocking call to your backend, at your
own taste. E.g. this call
invokes ags_audio_set_pads().

The timeout function polls your messages and forwards the event:

AgsMachine::resize-pads() is part of the UI. You listen to this event within UI.

Connect as usual, note the callback does modify is_available to TRUE:

do_wait = TRUE;
is_available = FALSE;

g_signal_connect_after(machine, "resize-pads",
   G_CALLBACK(pads_resized_callback),
_available);

Meanwhile you pause execution of UI by calling within gtk_main().

while((do_wait && !is_available[0])){
usleep(100 / 30);
g_main_context_iteration(NULL,
FALSE);
}

Your source is dispatched but gtk_main() is still within the loop shown above.

Bests,
Joël

On Thu, Jan 25, 2018 at 11:54 PM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi,
>
> Well there was some redundant code. This actually fixes it:
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/file/ags_simple_file.c?h=1.5.x#n1904
>
> Bests,
> Joël
>
>
> On Thu, Jan 25, 2018 at 11:16 PM, Joël Krähemann <jkraehem...@gmail.com> 
> wrote:
>> Hi,
>> You do some async work? Read about:
>>
>> g_timeout_add_full();
>>
>> and
>>
>> g_main_context_iteration();
>>
>> You, can callback the to the UI forwarded event. I do something similar
>> as reading a file from a different thread:
>>
>> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/file/ags_simple_file.c?h=1.4.x#n1957
>>
>> FYI: the UI thread shall run always by gtk_main().
>>
>> Bests,
>> Joël
>>
>> On Thu, Jan 25, 2018 at 11:10 PM, Alexander Koeppe
>> <alexander@koeppe.rocks> wrote:
>>> Thanks Lucky,
>>>
>>> Good idea to create the widget right away and hide it until it's time.
>>>
>>> However, just by accident, I got back the app-menu in the window.
>>>
>>> Try this with the code below:
>>>
>>> 1. After I selected "Restart" simulating the pause and resume, the
>>> app-menu disappeared.
>>> 2. Then I double-clicked the header-bar to maximise the window and the
>>> app-menu reappeared.
>>> 3. Again double-clicked the header-bar to restore the original geometry
>>> the app-menu is still there.
>>>
>>> This is what I want. Question is, what happens when I double click the
>>> header-bar and can I emulate this event in code?
>>>
>>> I feel being just 1 grain off my goal
>>>
>>> Thanks
>>>
>>>-Alex
>>>
>>>
>>> Am 23.01.2018 um 22:37 schrieb Lucky B.C:
>>>> Wow, I see your problem is that you did not understand what GtkBuilder
>>>> and Gtk are doing, Because If I'm not wrong, each choice (entry) is a
>>>> function to start something you want to do after the user/you clicked
>>>> to the button called "restart". Here's my solution, it's maybe help
>>>> you.
>>>>
>>>> *) You can use gtk_widget_hide (target) function to hide any widget,
>>>> in this case it's the main window. Then you can do your low-level
>>>> functions what the other can see at the time after the signal
>>>> "clicked" activated.
>>>>
>>>> Note: Some programs I saw the program did not exit when it's called to
>>>> restart, there's only the changed/related data must be reload to
>>>> buffer/ram, and the program must stop rendering/running at the time,
>>>> after the reloading's done the program continues to render/display the
>>>> new data in the screen. The reloading can be done in a new thread too,
>>>> after used you can delete it too.
>>>>
>>>> On Wed, Jan 24, 2018 at 2:52 AM, Alexander Koeppe
>>>> <alexander@koeppe.rocks> wrote:
>>>>> I know about the possiblity to fire the low-level functions using an 
>>>>> button
>>>>> callback. However this would draw an exception for other UI choices the
>>>>> application has: e.g. text, deamon.
>>>>>
>>>>> Therefore I'm looking for a way to keep the application structure for all
>>>>> UIs the same.
>>>>>
>>>>> There is the test

Re: Pause and resume GtkApplication

[Joël Krähemann]

Hi,

Well there was some redundant code. This actually fixes it:

http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/file/ags_simple_file.c?h=1.5.x#n1904

Bests,
Joël


On Thu, Jan 25, 2018 at 11:16 PM, Joël Krähemann <jkraehem...@gmail.com> wrote:
> Hi,
> You do some async work? Read about:
>
> g_timeout_add_full();
>
> and
>
> g_main_context_iteration();
>
> You, can callback the to the UI forwarded event. I do something similar
> as reading a file from a different thread:
>
> http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/file/ags_simple_file.c?h=1.4.x#n1957
>
> FYI: the UI thread shall run always by gtk_main().
>
> Bests,
> Joël
>
> On Thu, Jan 25, 2018 at 11:10 PM, Alexander Koeppe
> <alexander@koeppe.rocks> wrote:
>> Thanks Lucky,
>>
>> Good idea to create the widget right away and hide it until it's time.
>>
>> However, just by accident, I got back the app-menu in the window.
>>
>> Try this with the code below:
>>
>> 1. After I selected "Restart" simulating the pause and resume, the
>> app-menu disappeared.
>> 2. Then I double-clicked the header-bar to maximise the window and the
>> app-menu reappeared.
>> 3. Again double-clicked the header-bar to restore the original geometry
>> the app-menu is still there.
>>
>> This is what I want. Question is, what happens when I double click the
>> header-bar and can I emulate this event in code?
>>
>> I feel being just 1 grain off my goal
>>
>> Thanks
>>
>>-Alex
>>
>>
>> Am 23.01.2018 um 22:37 schrieb Lucky B.C:
>>> Wow, I see your problem is that you did not understand what GtkBuilder
>>> and Gtk are doing, Because If I'm not wrong, each choice (entry) is a
>>> function to start something you want to do after the user/you clicked
>>> to the button called "restart". Here's my solution, it's maybe help
>>> you.
>>>
>>> *) You can use gtk_widget_hide (target) function to hide any widget,
>>> in this case it's the main window. Then you can do your low-level
>>> functions what the other can see at the time after the signal
>>> "clicked" activated.
>>>
>>> Note: Some programs I saw the program did not exit when it's called to
>>> restart, there's only the changed/related data must be reload to
>>> buffer/ram, and the program must stop rendering/running at the time,
>>> after the reloading's done the program continues to render/display the
>>> new data in the screen. The reloading can be done in a new thread too,
>>> after used you can delete it too.
>>>
>>> On Wed, Jan 24, 2018 at 2:52 AM, Alexander Koeppe
>>> <alexander@koeppe.rocks> wrote:
>>>> I know about the possiblity to fire the low-level functions using an button
>>>> callback. However this would draw an exception for other UI choices the
>>>> application has: e.g. text, deamon.
>>>>
>>>> Therefore I'm looking for a way to keep the application structure for all
>>>> UIs the same.
>>>>
>>>> There is the test app I'm playing with:
>>>>
>>>>
>>>> #include 
>>>>
>>>> GtkApplication *app;
>>>> GtkWidget *window;
>>>> int initialized = 0;
>>>>
>>>> void quit_cb(GSimpleAction *action, GVariant *value, gpointer data)
>>>> {
>>>>g_print("quit!\n");
>>>>g_object_unref(app);
>>>>exit(0);
>>>> }
>>>>
>>>> void restart_cb(GSimpleAction *action, GVariant *value, gpointer data)
>>>> {
>>>>g_print("restart!\n");
>>>>g_application_quit(G_APPLICATION(app));
>>>> }
>>>>
>>>> void test_cb(GSimpleAction *action, GVariant *value, gpointer data)
>>>> {
>>>>   GtkWidget *dialog;
>>>>   GtkDialogFlags flags = GTK_DIALOG_DESTROY_WITH_PARENT;
>>>>
>>>>
>>>>   dialog = gtk_message_dialog_new(GTK_WINDOW(window),
>>>>   flags,
>>>>   GTK_MESSAGE_ERROR,
>>>>   GTK_BUTTONS_CLOSE,
>>>>   "TEst Message");
>>>>   g_signal_connect_swapped(dialog, "response",
>>>>G_CALLBACK(gtk_widget_destroy),
>>>>dialog);
>

Re: Pause and resume GtkApplication

[Joël Krähemann]

Hi,
You do some async work? Read about:

g_timeout_add_full();

and

g_main_context_iteration();

You, can callback the to the UI forwarded event. I do something similar
as reading a file from a different thread:

http://git.savannah.nongnu.org/cgit/gsequencer.git/tree/ags/X/file/ags_simple_file.c?h=1.4.x#n1957

FYI: the UI thread shall run always by gtk_main().

Bests,
Joël

On Thu, Jan 25, 2018 at 11:10 PM, Alexander Koeppe
<alexander@koeppe.rocks> wrote:
> Thanks Lucky,
>
> Good idea to create the widget right away and hide it until it's time.
>
> However, just by accident, I got back the app-menu in the window.
>
> Try this with the code below:
>
> 1. After I selected "Restart" simulating the pause and resume, the
> app-menu disappeared.
> 2. Then I double-clicked the header-bar to maximise the window and the
> app-menu reappeared.
> 3. Again double-clicked the header-bar to restore the original geometry
> the app-menu is still there.
>
> This is what I want. Question is, what happens when I double click the
> header-bar and can I emulate this event in code?
>
> I feel being just 1 grain off my goal
>
> Thanks
>
>-Alex
>
>
> Am 23.01.2018 um 22:37 schrieb Lucky B.C:
>> Wow, I see your problem is that you did not understand what GtkBuilder
>> and Gtk are doing, Because If I'm not wrong, each choice (entry) is a
>> function to start something you want to do after the user/you clicked
>> to the button called "restart". Here's my solution, it's maybe help
>> you.
>>
>> *) You can use gtk_widget_hide (target) function to hide any widget,
>> in this case it's the main window. Then you can do your low-level
>> functions what the other can see at the time after the signal
>> "clicked" activated.
>>
>> Note: Some programs I saw the program did not exit when it's called to
>> restart, there's only the changed/related data must be reload to
>> buffer/ram, and the program must stop rendering/running at the time,
>> after the reloading's done the program continues to render/display the
>> new data in the screen. The reloading can be done in a new thread too,
>> after used you can delete it too.
>>
>> On Wed, Jan 24, 2018 at 2:52 AM, Alexander Koeppe
>> <alexander@koeppe.rocks> wrote:
>>> I know about the possiblity to fire the low-level functions using an button
>>> callback. However this would draw an exception for other UI choices the
>>> application has: e.g. text, deamon.
>>>
>>> Therefore I'm looking for a way to keep the application structure for all
>>> UIs the same.
>>>
>>> There is the test app I'm playing with:
>>>
>>>
>>> #include 
>>>
>>> GtkApplication *app;
>>> GtkWidget *window;
>>> int initialized = 0;
>>>
>>> void quit_cb(GSimpleAction *action, GVariant *value, gpointer data)
>>> {
>>>g_print("quit!\n");
>>>g_object_unref(app);
>>>exit(0);
>>> }
>>>
>>> void restart_cb(GSimpleAction *action, GVariant *value, gpointer data)
>>> {
>>>g_print("restart!\n");
>>>g_application_quit(G_APPLICATION(app));
>>> }
>>>
>>> void test_cb(GSimpleAction *action, GVariant *value, gpointer data)
>>> {
>>>   GtkWidget *dialog;
>>>   GtkDialogFlags flags = GTK_DIALOG_DESTROY_WITH_PARENT;
>>>
>>>
>>>   dialog = gtk_message_dialog_new(GTK_WINDOW(window),
>>>   flags,
>>>   GTK_MESSAGE_ERROR,
>>>   GTK_BUTTONS_CLOSE,
>>>   "TEst Message");
>>>   g_signal_connect_swapped(dialog, "response",
>>>G_CALLBACK(gtk_widget_destroy),
>>>dialog);
>>>   gtk_dialog_run(GTK_DIALOG(dialog));
>>> }
>>>
>>> static void shutdown(GtkApplication *app, gpointer data)
>>> {
>>>initialized = 1;
>>> }
>>>
>>> static void
>>> activate (GtkApplication *app,
>>>   gpointeruser_data)
>>> {
>>>   GtkWidget *header, *menubutton, *frame, *overlay, *combo, *box;
>>>   GtkBuilder *builder;
>>>
>>>   GActionEntry actions[] = {
>>>   {"test_action", test_cb, NULL, NULL, NULL,{}},
>>>   {"restart", restart_cb, NULL, NULL, NULL, {}},
>>>   {"quit", qui

Re: Pause and resume GtkApplication

[Alexander Koeppe]

Thanks Lucky,

Good idea to create the widget right away and hide it until it's time.

However, just by accident, I got back the app-menu in the window.

Try this with the code below:

1. After I selected "Restart" simulating the pause and resume, the
app-menu disappeared.
2. Then I double-clicked the header-bar to maximise the window and the
app-menu reappeared.
3. Again double-clicked the header-bar to restore the original geometry
the app-menu is still there.

This is what I want. Question is, what happens when I double click the
header-bar and can I emulate this event in code?

I feel being just 1 grain off my goal

Thanks

   -Alex


Am 23.01.2018 um 22:37 schrieb Lucky B.C:
> Wow, I see your problem is that you did not understand what GtkBuilder
> and Gtk are doing, Because If I'm not wrong, each choice (entry) is a
> function to start something you want to do after the user/you clicked
> to the button called "restart". Here's my solution, it's maybe help
> you.
>
> *) You can use gtk_widget_hide (target) function to hide any widget,
> in this case it's the main window. Then you can do your low-level
> functions what the other can see at the time after the signal
> "clicked" activated.
>
> Note: Some programs I saw the program did not exit when it's called to
> restart, there's only the changed/related data must be reload to
> buffer/ram, and the program must stop rendering/running at the time,
> after the reloading's done the program continues to render/display the
> new data in the screen. The reloading can be done in a new thread too,
> after used you can delete it too.
>
> On Wed, Jan 24, 2018 at 2:52 AM, Alexander Koeppe
> <alexander@koeppe.rocks> wrote:
>> I know about the possiblity to fire the low-level functions using an button
>> callback. However this would draw an exception for other UI choices the
>> application has: e.g. text, deamon.
>>
>> Therefore I'm looking for a way to keep the application structure for all
>> UIs the same.
>>
>> There is the test app I'm playing with:
>>
>>
>> #include 
>>
>> GtkApplication *app;
>> GtkWidget *window;
>> int initialized = 0;
>>
>> void quit_cb(GSimpleAction *action, GVariant *value, gpointer data)
>> {
>>g_print("quit!\n");
>>g_object_unref(app);
>>exit(0);
>> }
>>
>> void restart_cb(GSimpleAction *action, GVariant *value, gpointer data)
>> {
>>g_print("restart!\n");
>>g_application_quit(G_APPLICATION(app));
>> }
>>
>> void test_cb(GSimpleAction *action, GVariant *value, gpointer data)
>> {
>>   GtkWidget *dialog;
>>   GtkDialogFlags flags = GTK_DIALOG_DESTROY_WITH_PARENT;
>>
>>
>>   dialog = gtk_message_dialog_new(GTK_WINDOW(window),
>>   flags,
>>   GTK_MESSAGE_ERROR,
>>   GTK_BUTTONS_CLOSE,
>>   "TEst Message");
>>   g_signal_connect_swapped(dialog, "response",
>>G_CALLBACK(gtk_widget_destroy),
>>dialog);
>>   gtk_dialog_run(GTK_DIALOG(dialog));
>> }
>>
>> static void shutdown(GtkApplication *app, gpointer data)
>> {
>>initialized = 1;
>> }
>>
>> static void
>> activate (GtkApplication *app,
>>   gpointeruser_data)
>> {
>>   GtkWidget *header, *menubutton, *frame, *overlay, *combo, *box;
>>   GtkBuilder *builder;
>>
>>   GActionEntry actions[] = {
>>   {"test_action", test_cb, NULL, NULL, NULL,{}},
>>   {"restart", restart_cb, NULL, NULL, NULL, {}},
>>   {"quit", quit_cb, NULL, NULL, NULL, {}}
>>   };
>>
>>
>>   g_action_map_add_action_entries(G_ACTION_MAP(app), actions,
>>   G_N_ELEMENTS(actions), app);
>>
>>
>>
>>   if (initialized == 0) {
>>  window = gtk_application_window_new (app);
>>  gtk_window_set_default_size (GTK_WINDOW (window), 500, 300);
>>   }
>>   else {
>>  gtk_application_add_window(app, GTK_WINDOW(window));
>>   }
>>   gtk_window_set_title (GTK_WINDOW (window), "buildertest");
>>
>>   /* Header Bar */
>>   header = gtk_header_bar_new();
>>   gtk_header_bar_set_title(GTK_HEADER_BAR(header), "Yeah");
>>   gtk_header_bar_set_show_close_button(GTK_HEADER_BAR(header), TRUE);
>>   gtk_window_set_titlebar(GTK_WINDOW(window), header)

Re: Pause and resume GtkApplication

[Lucky B.C]

Wow, I see your problem is that you did not understand what GtkBuilder
and Gtk are doing, Because If I'm not wrong, each choice (entry) is a
function to start something you want to do after the user/you clicked
to the button called "restart". Here's my solution, it's maybe help
you.

*) You can use gtk_widget_hide (target) function to hide any widget,
in this case it's the main window. Then you can do your low-level
functions what the other can see at the time after the signal
"clicked" activated.

Note: Some programs I saw the program did not exit when it's called to
restart, there's only the changed/related data must be reload to
buffer/ram, and the program must stop rendering/running at the time,
after the reloading's done the program continues to render/display the
new data in the screen. The reloading can be done in a new thread too,
after used you can delete it too.

On Wed, Jan 24, 2018 at 2:52 AM, Alexander Koeppe
<alexander@koeppe.rocks> wrote:
> I know about the possiblity to fire the low-level functions using an button
> callback. However this would draw an exception for other UI choices the
> application has: e.g. text, deamon.
>
> Therefore I'm looking for a way to keep the application structure for all
> UIs the same.
>
> There is the test app I'm playing with:
>
>
> #include 
>
> GtkApplication *app;
> GtkWidget *window;
> int initialized = 0;
>
> void quit_cb(GSimpleAction *action, GVariant *value, gpointer data)
> {
>g_print("quit!\n");
>g_object_unref(app);
>exit(0);
> }
>
> void restart_cb(GSimpleAction *action, GVariant *value, gpointer data)
> {
>g_print("restart!\n");
>g_application_quit(G_APPLICATION(app));
> }
>
> void test_cb(GSimpleAction *action, GVariant *value, gpointer data)
> {
>   GtkWidget *dialog;
>   GtkDialogFlags flags = GTK_DIALOG_DESTROY_WITH_PARENT;
>
>
>   dialog = gtk_message_dialog_new(GTK_WINDOW(window),
>   flags,
>   GTK_MESSAGE_ERROR,
>   GTK_BUTTONS_CLOSE,
>   "TEst Message");
>   g_signal_connect_swapped(dialog, "response",
>G_CALLBACK(gtk_widget_destroy),
>    dialog);
>   gtk_dialog_run(GTK_DIALOG(dialog));
> }
>
> static void shutdown(GtkApplication *app, gpointer data)
> {
>initialized = 1;
> }
>
> static void
> activate (GtkApplication *app,
>   gpointeruser_data)
> {
>   GtkWidget *header, *menubutton, *frame, *overlay, *combo, *box;
>   GtkBuilder *builder;
>
>   GActionEntry actions[] = {
>   {"test_action", test_cb, NULL, NULL, NULL,{}},
>   {"restart", restart_cb, NULL, NULL, NULL, {}},
>   {"quit", quit_cb, NULL, NULL, NULL, {}}
>   };
>
>
>   g_action_map_add_action_entries(G_ACTION_MAP(app), actions,
>   G_N_ELEMENTS(actions), app);
>
>
>
>   if (initialized == 0) {
>  window = gtk_application_window_new (app);
>  gtk_window_set_default_size (GTK_WINDOW (window), 500, 300);
>   }
>   else {
>  gtk_application_add_window(app, GTK_WINDOW(window));
>   }
>   gtk_window_set_title (GTK_WINDOW (window), "buildertest");
>
>   /* Header Bar */
>   header = gtk_header_bar_new();
>   gtk_header_bar_set_title(GTK_HEADER_BAR(header), "Yeah");
>   gtk_header_bar_set_show_close_button(GTK_HEADER_BAR(header), TRUE);
>   gtk_window_set_titlebar(GTK_WINDOW(window), header);
>
>   /* Menu Button */
>   menubutton = gtk_menu_button_new();
>
>   /* Menu for Menubutton */
>   builder = gtk_builder_new();
>   gtk_builder_add_from_string(builder,
>  ""
>  "  "
>  ""
>  "  "
>  " translatable='yes'>Restart"
>  "app.restart"
>  "  "
>  "  "
>  " translatable='yes'>Quit"
>  "app.quit"
>  "  "
>  ""
>  "  "
>  "  "
>  ""
>  "Test"
>  "  "
>  "Test
> Entry"
>  "app.test_action"
>  "t"
>  "  "
>  ""
>  "  "
>  "", -1, NULL);
>
>   gtk_application_set_app_menu(GTK_APPLICATION(app),
> G_MENU_MODEL(gtk_builder_get_object(

Re: Pause and resume GtkApplication

[Alexander Koeppe]

I know about the possiblity to fire the low-level functions using an
button callback. However this would draw an exception for other UI
choices the application has: e.g. text, deamon.

Therefore I'm looking for a way to keep the application structure for
all UIs the same.

There is the test app I'm playing with:


#include 

GtkApplication *app;
GtkWidget *window;
int initialized = 0;

void quit_cb(GSimpleAction *action, GVariant *value, gpointer data)
{
   g_print("quit!\n");
   g_object_unref(app);
   exit(0);
}

void restart_cb(GSimpleAction *action, GVariant *value, gpointer data)
{
   g_print("restart!\n");
   g_application_quit(G_APPLICATION(app));
}

void test_cb(GSimpleAction *action, GVariant *value, gpointer data)
{
  GtkWidget *dialog;
  GtkDialogFlags flags = GTK_DIALOG_DESTROY_WITH_PARENT;


  dialog = gtk_message_dialog_new(GTK_WINDOW(window),
  flags,
  GTK_MESSAGE_ERROR,
  GTK_BUTTONS_CLOSE,
  "TEst Message");
  g_signal_connect_swapped(dialog, "response",
   G_CALLBACK(gtk_widget_destroy),
   dialog);
  gtk_dialog_run(GTK_DIALOG(dialog));
}

static void shutdown(GtkApplication *app, gpointer data)
{
   initialized = 1;
}

static void
activate (GtkApplication *app,
  gpointer    user_data)
{
  GtkWidget *header, *menubutton, *frame, *overlay, *combo, *box;
  GtkBuilder *builder;

  GActionEntry actions[] = {
  {"test_action", test_cb, NULL, NULL, NULL,{}},
  {"restart", restart_cb, NULL, NULL, NULL, {}},
  {"quit", quit_cb, NULL, NULL, NULL, {}}
  };


  g_action_map_add_action_entries(G_ACTION_MAP(app), actions,
  G_N_ELEMENTS(actions), app);



  if (initialized == 0) {
 window = gtk_application_window_new (app);
 gtk_window_set_default_size (GTK_WINDOW (window), 500, 300);
  }
  else {
 gtk_application_add_window(app, GTK_WINDOW(window));
  }
  gtk_window_set_title (GTK_WINDOW (window), "buildertest");

  /* Header Bar */
  header = gtk_header_bar_new();
  gtk_header_bar_set_title(GTK_HEADER_BAR(header), "Yeah");
  gtk_header_bar_set_show_close_button(GTK_HEADER_BAR(header), TRUE);
  gtk_window_set_titlebar(GTK_WINDOW(window), header);

  /* Menu Button */
  menubutton = gtk_menu_button_new();

  /* Menu for Menubutton */
  builder = gtk_builder_new();
  gtk_builder_add_from_string(builder,
 ""
 "  "
 "    "
 "  "
 "    Restart"
 "    app.restart"
 "  "
 "  "
 "    Quit"
 "    app.quit"
 "  "
 "    "
 "  "
 "  "
 "    "
 "    Test"
 "  "
 "    Test
Entry"
 "    app.test_action"
 "    t"
 "  "
 "    "
 "  "
 "", -1, NULL);

  gtk_application_set_app_menu(GTK_APPLICATION(app),
    G_MENU_MODEL(gtk_builder_get_object(builder, "app-menu")));

  gtk_menu_button_set_menu_model(GTK_MENU_BUTTON(menubutton),
  G_MENU_MODEL(gtk_builder_get_object(builder, "test-menu")));

  gtk_button_set_image(GTK_BUTTON(menubutton),
   gtk_image_new_from_icon_name("open-menu-symbolic",
GTK_ICON_SIZE_MENU));
  gtk_header_bar_pack_end(GTK_HEADER_BAR(header), menubutton);

  /* content area */
  if (initialized) {
 overlay = gtk_bin_get_child(GTK_BIN(window));
 gtk_container_remove(GTK_CONTAINER(window), overlay);
  }

  overlay = gtk_overlay_new();
  gtk_container_add(GTK_CONTAINER(window), overlay);

  frame = gtk_frame_new("Rahmen");
  gtk_container_add(GTK_CONTAINER(overlay), frame);

  box = gtk_box_new(GTK_ORIENTATION_VERTICAL, 5);
  gtk_container_add(GTK_CONTAINER(frame), box);

  combo = gtk_combo_box_text_new();
  gtk_combo_box_text_append(GTK_COMBO_BOX_TEXT(combo), "id1", "Entry 1");
  gtk_combo_box_text_append(GTK_COMBO_BOX_TEXT(combo), "id2", "Entry 2");
  gtk_combo_box_set_active(GTK_COMBO_BOX(combo), 0);
  gtk_widget_set_hexpand(combo, TRUE);

  gtk_box_pack_start(GTK_BOX(box), combo, FALSE, FALSE, 0);



  gtk_widget_show_all(window);
}

int main(int   argc,
 char *argv[])
{
  app = NULL;
  int status;

  app = gtk_application_new ("org.gnome.Buildertest",
G_APPLICATION_FLAGS_NONE);
  g_signal_connect (app, "activate", G_CALLBACK (activate), NULL);
  g_signal_connect (app, "shutdown", G_CALLBACK(shutdown), NULL);
  status = g_application_run (G_APPLICATION (app), argc, argv);

  g_pr

Re: Pause and resume GtkApplication

[Lucky B.C]

Hi, can you show your demo about the way you did? But I think you should
keep the gtk_main() runs, because you can run your low-level functions by
"clicked" signal on button.

On Jan 23, 2018 03:44, "Alexander Koeppe"  wrote:

Hi,

I have an application where some things need to be setup in the UI, then
some low-level routines to be executed using the setup values and then
resuming the UI loop for further operation.

Since I'm migrating the GTK code from GTK2/3 compatible to GNOME/GTK3, I
make use of g_application_run().

However, I find no simialar way to interrupt the loop (e.g.
gtk_main_quit()) and resuming the UI later (gtk_main()).

The only way I found yet is to quit the application using
g_application_quit() but keep the window widget, clearing the
application (g_object_unref()) and creating a new application after
executing the low-level routines and finally adding the still existing
window widget to this new application using
gtk_application_add_window(). This way I can reuse the window and avoid
any flickering which is the required effect.

The only caveat is, the added window is not considered being the primary
instance of the second application, hence the app-menu isn't displayed.

Is there any way to define a window added being the primary instance of
the application or to show the app-menu (set using
gtk_application_set_app_menu()) in such an non-primary window, or even a
complete different approach?


Thanks and regards

- Alex


___
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

Pause and resume GtkApplication

[Alexander Koeppe]

Hi,

I have an application where some things need to be setup in the UI, then
some low-level routines to be executed using the setup values and then
resuming the UI loop for further operation.

Since I'm migrating the GTK code from GTK2/3 compatible to GNOME/GTK3, I
make use of g_application_run().

However, I find no simialar way to interrupt the loop (e.g.
gtk_main_quit()) and resuming the UI later (gtk_main()).

The only way I found yet is to quit the application using
g_application_quit() but keep the window widget, clearing the
application (g_object_unref()) and creating a new application after
executing the low-level routines and finally adding the still existing
window widget to this new application using
gtk_application_add_window(). This way I can reuse the window and avoid
any flickering which is the required effect.

The only caveat is, the added window is not considered being the primary
instance of the second application, hence the app-menu isn't displayed.

Is there any way to define a window added being the primary instance of
the application or to show the app-menu (set using
gtk_application_set_app_menu()) in such an non-primary window, or even a
complete different approach?


Thanks and regards

- Alex


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

Re: GtkApplication with different ApplicationWindows

[zahlenmeer]

I tested it with "normal" GtkWindows, and yes, they work the same way
GtkApplicationWindows do.
But in my case I have multiple application windows with different
semantics. And this is not the intention behind GtkApplication. I guess
I could make it work, but it would be really happy and result in unnice
code.
One could argue that my requirements are the result of bad application
design but I am quite happy with this approach. I will go a similar way
Joel has suggested. I will derive my own application object from
GApplication, not GtkApplication, so I have all the wonderful things
like process uniqueness, DBus communication, and so on and in my own
object I will implement window tracking with my application-specific
semantics.

On 08/15/16 00:13, Victor Aurélio Santos wrote:
> This is what i found on the GtkApplication docs:
> 
>> While GtkApplication works fine with plain GtkWindows, it is recommended to 
>> use it together with GtkApplicationWindow.
> 
> So, you can use just a GtkWindow, or "TaskWindow" for say...
> 
> I've not tested, but it should work.
> 
> 2016-08-13 10:21 GMT-03:00  <zahlenm...@gmx.de>:
>> This is exactly what I thought of, but I also want to allow to run my
>> program without the main window (like ./prog --task which only opens a
>> task window). So I would have to run a GtkApplication without any
>> GtkApplicationWindow. As the applications life cycle is tied to its
>> ApplicationWindows this approach just seems wrong.
>>
>> On 08/13/16 14:14, Victor Aurélio Santos wrote:
>>> GtkApplicationWindow, loads a menubar  from resources automatically if
>>> they exists.
>>> So, You can have main window as GtkApplicationWindow and have tasks as
>>> GtkWindow.
>>>
>>> For GtkWindow you'll add a GtkMenuBar to it as any widget.
>>>
>>> I'm not a Gtk+ expert, but this is how I would do.
>>>
>>> 2016-08-13 8:22 GMT-03:00  <zahlenm...@gmx.de>:
>>>> Hi everyone,
>>>> I am working on a project where I am struggling to decide which
>>>> classes/objects I should use. I use gtk3 but it's still a classical
>>>> application, so no fancy appmenu, CSD and not primarily designed for the
>>>> Gnome DE.
>>>>
>>>> The program works as follows:
>>>> - A unique main window, with a main menu bar
>>>> - Multiple task windows, all with a task menu bar
>>>> - The program can be called with ./prog --task to only open the task
>>>> window, not the main window
>>>>
>>>> The first thing one would find in the documentation is GtkApplication
>>>> and GtkApplicationWindow, but those have some limitations I currently
>>>> don't know how to deal with:
>>>> - Different menubars for different windows (main window vs. task window)
>>>>
>>>> So the idea would be to use a normal GtkWindow for the task windows, but
>>>> in this case I have:
>>>> - Application life-cycle without a GtkApplicationWindow?
>>>>
>>>> So for me the most promising solution would be to skip GtkApplication
>>>> and GtkApplicationWindow at all, using plain GtkWindows and writing my
>>>> custom application class. Of course this means extra work to get all the
>>>> nice benefits GtkApplication offers out of the box.
>>>>
>>>> Do you have any ideas how I could design my application accordingly?
>>>>
>>>> Kind regards
>>>> ___
>>>> 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
> 
> 
> 
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkApplication with different ApplicationWindows

[Victor Aurélio Santos]

This is what i found on the GtkApplication docs:

> While GtkApplication works fine with plain GtkWindows, it is recommended to 
> use it together with GtkApplicationWindow.

So, you can use just a GtkWindow, or "TaskWindow" for say...

I've not tested, but it should work.

2016-08-13 10:21 GMT-03:00  <zahlenm...@gmx.de>:
> This is exactly what I thought of, but I also want to allow to run my
> program without the main window (like ./prog --task which only opens a
> task window). So I would have to run a GtkApplication without any
> GtkApplicationWindow. As the applications life cycle is tied to its
> ApplicationWindows this approach just seems wrong.
>
> On 08/13/16 14:14, Victor Aurélio Santos wrote:
>> GtkApplicationWindow, loads a menubar  from resources automatically if
>> they exists.
>> So, You can have main window as GtkApplicationWindow and have tasks as
>> GtkWindow.
>>
>> For GtkWindow you'll add a GtkMenuBar to it as any widget.
>>
>> I'm not a Gtk+ expert, but this is how I would do.
>>
>> 2016-08-13 8:22 GMT-03:00  <zahlenm...@gmx.de>:
>>> Hi everyone,
>>> I am working on a project where I am struggling to decide which
>>> classes/objects I should use. I use gtk3 but it's still a classical
>>> application, so no fancy appmenu, CSD and not primarily designed for the
>>> Gnome DE.
>>>
>>> The program works as follows:
>>> - A unique main window, with a main menu bar
>>> - Multiple task windows, all with a task menu bar
>>> - The program can be called with ./prog --task to only open the task
>>> window, not the main window
>>>
>>> The first thing one would find in the documentation is GtkApplication
>>> and GtkApplicationWindow, but those have some limitations I currently
>>> don't know how to deal with:
>>> - Different menubars for different windows (main window vs. task window)
>>>
>>> So the idea would be to use a normal GtkWindow for the task windows, but
>>> in this case I have:
>>> - Application life-cycle without a GtkApplicationWindow?
>>>
>>> So for me the most promising solution would be to skip GtkApplication
>>> and GtkApplicationWindow at all, using plain GtkWindows and writing my
>>> custom application class. Of course this means extra work to get all the
>>> nice benefits GtkApplication offers out of the box.
>>>
>>> Do you have any ideas how I could design my application accordingly?
>>>
>>> Kind regards
>>> ___
>>> 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



-- 
Victor Aurélio Santos
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkApplication with different ApplicationWindows

[zahlenmeer]

This is exactly what I thought of, but I also want to allow to run my
program without the main window (like ./prog --task which only opens a
task window). So I would have to run a GtkApplication without any
GtkApplicationWindow. As the applications life cycle is tied to its
ApplicationWindows this approach just seems wrong.

On 08/13/16 14:14, Victor Aurélio Santos wrote:
> GtkApplicationWindow, loads a menubar  from resources automatically if
> they exists.
> So, You can have main window as GtkApplicationWindow and have tasks as
> GtkWindow.
> 
> For GtkWindow you'll add a GtkMenuBar to it as any widget.
> 
> I'm not a Gtk+ expert, but this is how I would do.
> 
> 2016-08-13 8:22 GMT-03:00  <zahlenm...@gmx.de>:
>> Hi everyone,
>> I am working on a project where I am struggling to decide which
>> classes/objects I should use. I use gtk3 but it's still a classical
>> application, so no fancy appmenu, CSD and not primarily designed for the
>> Gnome DE.
>>
>> The program works as follows:
>> - A unique main window, with a main menu bar
>> - Multiple task windows, all with a task menu bar
>> - The program can be called with ./prog --task to only open the task
>> window, not the main window
>>
>> The first thing one would find in the documentation is GtkApplication
>> and GtkApplicationWindow, but those have some limitations I currently
>> don't know how to deal with:
>> - Different menubars for different windows (main window vs. task window)
>>
>> So the idea would be to use a normal GtkWindow for the task windows, but
>> in this case I have:
>> - Application life-cycle without a GtkApplicationWindow?
>>
>> So for me the most promising solution would be to skip GtkApplication
>> and GtkApplicationWindow at all, using plain GtkWindows and writing my
>> custom application class. Of course this means extra work to get all the
>> nice benefits GtkApplication offers out of the box.
>>
>> Do you have any ideas how I could design my application accordingly?
>>
>> Kind regards
>> ___
>> 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: GtkApplication with different ApplicationWindows

[Victor Aurélio Santos]

GtkApplicationWindow, loads a menubar  from resources automatically if
they exists.
So, You can have main window as GtkApplicationWindow and have tasks as
GtkWindow.

For GtkWindow you'll add a GtkMenuBar to it as any widget.

I'm not a Gtk+ expert, but this is how I would do.

2016-08-13 8:22 GMT-03:00  <zahlenm...@gmx.de>:
> Hi everyone,
> I am working on a project where I am struggling to decide which
> classes/objects I should use. I use gtk3 but it's still a classical
> application, so no fancy appmenu, CSD and not primarily designed for the
> Gnome DE.
>
> The program works as follows:
> - A unique main window, with a main menu bar
> - Multiple task windows, all with a task menu bar
> - The program can be called with ./prog --task to only open the task
> window, not the main window
>
> The first thing one would find in the documentation is GtkApplication
> and GtkApplicationWindow, but those have some limitations I currently
> don't know how to deal with:
> - Different menubars for different windows (main window vs. task window)
>
> So the idea would be to use a normal GtkWindow for the task windows, but
> in this case I have:
> - Application life-cycle without a GtkApplicationWindow?
>
> So for me the most promising solution would be to skip GtkApplication
> and GtkApplicationWindow at all, using plain GtkWindows and writing my
> custom application class. Of course this means extra work to get all the
> nice benefits GtkApplication offers out of the box.
>
> Do you have any ideas how I could design my application accordingly?
>
> Kind regards
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



-- 
Victor Aurélio Santos
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

GtkApplication with different ApplicationWindows

[zahlenmeer]

Hi everyone,
I am working on a project where I am struggling to decide which
classes/objects I should use. I use gtk3 but it's still a classical
application, so no fancy appmenu, CSD and not primarily designed for the
Gnome DE.

The program works as follows:
- A unique main window, with a main menu bar
- Multiple task windows, all with a task menu bar
- The program can be called with ./prog --task to only open the task
window, not the main window

The first thing one would find in the documentation is GtkApplication
and GtkApplicationWindow, but those have some limitations I currently
don't know how to deal with:
- Different menubars for different windows (main window vs. task window)

So the idea would be to use a normal GtkWindow for the task windows, but
in this case I have:
- Application life-cycle without a GtkApplicationWindow?

So for me the most promising solution would be to skip GtkApplication
and GtkApplicationWindow at all, using plain GtkWindows and writing my
custom application class. Of course this means extra work to get all the
nice benefits GtkApplication offers out of the box.

Do you have any ideas how I could design my application accordingly?

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

Re: Is GtkApplication example Bloatpad Parse supposed to be Paste?

[Matthias Clasen]

On Sat, Jun 23, 2012 at 1:33 AM, Micah Carrick mi...@quixotix.com wrote:
 I was working on getting up to speed with GtkApplication by implementing the
 Bloatpad example application in the GTK+ docs in Python. I noticed the UI
 XML has an action for win.parse for which there are not actions. There are
 actions for win.paste though. That's a typo... right ?

Looks like it, yes.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Is GtkApplication example Bloatpad Parse supposed to be Paste?

[Micah Carrick]

I was working on getting up to speed with GtkApplication by implementing
the Bloatpad example application in the GTK+ docs in Python. I noticed
the UI XML has an action for win.parse for which there are not actions.
There are actions for win.paste though. That's a typo... right?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

GtkApplication initialization tru command-line signal (vs activate or startup signals)

[Basile Starynkevitch]

Hello

I don't understand how GtkApplication and GApplication should be used.

I actually am not sure to understand why is GtkApplication really
useful. I believe it is using DBus to communicate with the session
manager, possibly to permit that only one instance is running. But I
don't understand the details

In particular, I don't understand why GtkApplication don't offer the
simplicity of initializing itself with program argument processing
like gtk_init_with_args do.
Apparently, to initialize such an application, one have to call
gtk_application_new with  G_APPLICATION_HANDLES_COMMAND_LINE and define
a handler for the command-line signal. 

I am not sure to understand why both activate and startup signal
exist for GtkApplications. In fact, I don't understand why they are
both needed.

My code looks like


  my_appl =
gtk_application_new (my.program, 
 G_APPLICATION_HANDLES_COMMAND_LINE);
  g_signal_connect (my_appl, command-line,
G_CALLBACK (my_command_line), NULL);
  g_signal_connect (my_appl, activate,
 G_CALLBACK (my_activate),
NULL);
  g_signal_connect (my_appl, startup, 
 G_CALLBACK (my_startup), NULL);
  if (g_application_register (G_APPLICATION (my_appl), 
NULL, err))
{
  g_debug (application registered);
}
  else
g_error (failed to register application %s, 
 err-message);
  g_debug (before activation);
  g_application_activate (G_APPLICATION (my_appl));
  g_debug (before run);
  status = g_application_run (G_APPLICATION (my_appl), 
argc, argv); 



But I notice that my_startup is called before end of registration, but
my_command_line is called only from g_application_run. So my_activate 
my_startup routines cannot take into account any program arguments processed 
by my_command_line!


I am probably doing something wrong. But what?

I also find very few examples of GtkApplication code. Do you know some?

Regards.



-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GTK+ 3, Win32 and GtkApplication (DBus woes)

[Alexander Larsson]

On Mon, 2011-03-28 at 16:54 +0200, Kean Johnston wrote:
 Since I am new to this list I am unsure of the etiquette involved in 
 discussing issues in integral underpinnings of GTK+ like Glib/Gio, and I 
 know there's a fair amount of cross-pollination of developers, but if 
 discussions of Glib/Gio issues, especially as related to GTK+ are unwelcome 
 or unproductive here, I'll move my questions to the appropriate place, 
 wherever that is.

There is no separate devel list for glib or gio, it all happens here.

For the GtkApplication part I just think someone will have to spend some
time on the GtkApplication code making sure it has a win32 specific
backend. Its a bit unfortunate that it landed before that was available,
but thats is often how things work in Gtk+ due to the severe lack of
manpower on the win32 side.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander LarssonRed Hat, Inc 
   al...@redhat.comalexander.lars...@gmail.com 
He's a lounge-singing skateboarding cop from the Mississippi delta. She's a 
disco-crazy blonde fairy princess with an incredible destiny. They fight 
crime! 

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

Re: GTK+ 3, Win32 and GtkApplication (DBus woes)

[Kean Johnston]

There is no separate devel list for glib or gio, it all happens here.

Thanks for the info. I have some ideas I need to mull around for a bit
that I'll post about in the near future.


For the GtkApplication part I just think someone will have to spend some
time on the GtkApplication code making sure it has a win32 specific
backend. Its a bit unfortunate that it landed before that was available,
but thats is often how things work in Gtk+ due to the severe lack of
manpower on the win32 side.


You can add me to that short list. I have 25+ years UNIX development
experience and I'm intimately familiar with the entire GNU toolchain
and all the autoconf nonsense, and I'm fairly adept at win32 as well
so it puts me in a good position to help. I tend to avoid contributing
to [L]GPL projects as much as possible but I do make exceptions and I am
happy to make one in this case, if for no other reason than that I have
a vested interest in seeing things work (which, after cold hard cash,
is one of the best motivators :)). That and the fact that GTK+ is really
very cool and fun and well written.

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

Re: GtkApplication and argc/arv

[Murray Cumming]

On Fri, 2011-03-25 at 11:48 -0400, Colin Walters wrote:
 On Mon, Mar 21, 2011 at 6:03 AM, Murray Cumming murr...@murrayc.com wrote:
 
  I very much like the re-show-instead-of-reopening idea, and miss it
  since I stopped using MacOS 7.3. However, I don't understand why this
  should require a single process.
 
 How do you recommend apps implement this then?

Via some interprocess communication, via a GtkApplication that makes
that easy? Obviously I can't recommend that apps do that now, hence this
discussion.

Or maybe via some session-wide tracking of open files? I have no idea. I
haven't investigated how it's done elsewhere.

But my own idle speculation isn't helping me find a justification for
the current code.

-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

GTK+ 3, Win32 and GtkApplication (DBus woes)

[Kean Johnston]

Hello everyone,

I am new to this list and I am attempting to write my first GTK+ 
application. For a change of pace, I decided to do my primary development 
on Windows instead of Linux, as the particular application I am writing 
will most likely be run most often on Windows. I chose GTK+ as the toolkit 
to use because of its portability, especially it's advertised portability 
to Windows and MacOS.


Please bear in mind that my perspective is not that of a GTK+ developer 
(although I will have a few patches for Win32 forthcoming soon) but rather 
as a consumer, and a new one at that, so all I have to go on is the 
provided documentation. Very early on in my reading, I was encouraged to 
not manually construct widgets but to use GtkUIManager, and tools like Glade.


I compiled Glade 3.9.2 and because it used GtkApplication, it no longer 
works on Windows. Gio aborts with Cannot determine session bus address 
(not implemented for this OS) because DBus support isn't complete in Gio. 
As I read the code this is unavoidable. Therefore, as things currently 
stand, if an application uses GtkApplication, it cannot ever run on Win32. 
An application can't ever use Glade for designing its UI either, because 
Glade uses GtkApplication. This really feels like an unintended consequence.


I read the thread in the archives that started with a discussion on 
argc/argv (that devolved into discussions of other tools and not the core 
issue), as well as a rename of the thread that seemed to indicate DBus 
support could be added but that it would involve dbus daemons and spawner 
and such, which is fine if all you are writing is OS applications, but if 
Glib/Gtk are meant to be real portable toolkits for applications, then 
requiring such an overhead is untenable. As things currently stand, I just 
don't think Glib/Gtk can realistically claim to support Win32 (for anything 
but a subset of their functionality).


Is there any way that a GtkApplication can be marked (some flag or such) as 
to not require DBus? Since the author of Glade was a frequent commentator 
on the previous thread about this, is there any way of not requiring 
g_application_run() (which starts the whole DBus mess)?


Any help / guidance appreciated, and I have development cycles I can spare 
to help test or possibly even implement changes.


Regards and thank you for your time and a phenomenal set of tools.

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

Re: GTK+ 3, Win32 and GtkApplication (DBus woes)

[Paul Davis]

On Mon, Mar 28, 2011 at 5:35 AM, Kean Johnston kean.johns...@gmail.com wrote:
 Hello everyone,

GtkApplication is a rather new piece of the GTK API. There has been
quite a bit of discussion about its role and its impact on cross
platform portability.

The answer for now is that if you want cross platform portability,
simply don't use GtkApplication. It didn't exist several months ago,
and there are plenty of excellent apps written with GTK that don't use
it.

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

Re: GTK+ 3, Win32 and GtkApplication (DBus woes)

[Kean Johnston]

On 3/28/2011 1:12 PM, Paul Davis wrote:

On Mon, Mar 28, 2011 at 5:35 AM, Kean Johnstonkean.johns...@gmail.com  wrote:

Hello everyone,


GtkApplication is a rather new piece of the GTK API. There has been
quite a bit of discussion about its role and its impact on cross
platform portability.
I'll try read more of the mailing list archive. I have a vested interest in 
Gtk+ 3 on Win32 and MacOS, so if ever any help is needed or wanted testing 
any changes, I am very happy to help.



The answer for now is that if you want cross platform portability,
simply don't use GtkApplication. It didn't exist several months ago,
and there are plenty of excellent apps written with GTK that don't use
it.
In one particular case, namely using the current beta of Glade, I was 
able to get it to at least start working by extracting a previous version 
of main.c from git. Fortunately, the change the author made to use 
GtkApplication was in a single commit so it was easy to unwind.


My only concern about simply don't use it is that it seems (to me at 
least) as if newcomers are encouraged that way, and it currently isn't 
portable, as you stated. Considering what a long history Gtk+ has of being 
very portable, from the outside looking in it's a bit concerning that it 
even made it into the mainline in its current state considering its 
portability impact. I guess because the primary use platform is Linux it is 
very easy to loose sight of the fact that it is used elsewhere, since the 
vast majority of users will remain ignorantly happy.


People are very obviously aware of this impact, I'm just adding my voice to 
the mix keeping portability a primary, rather than secondary concern.


Thank you for your prompt reply.

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

Re: GTK+ 3, Win32 and GtkApplication (DBus woes)

[Paul Davis]

On Mon, Mar 28, 2011 at 7:26 AM, Kean Johnston kean.johns...@gmail.com wrote:
Considering what a long history Gtk+ has of being
 very portable,

I would say that this is a subtle mis-perception. GTK's support for
non *nix, non-X11 platforms has happened generally inspite of, rather
than because of any central portability goal. Its been implemented by
very small numbers of dedicated individuals for each platform, and is
frequently broken for relatively short periods of time as the
internals of GTK change. It is true that GTK is becoming *more*
portable as a result of the design changes we've seen in the last 2
years, and that this will continue. Its also at least as portable as
anything else with its power and flexibility. But for some reason, its
quite easy to get the idea that GTK was actually designed as a
cross-platform toolkit, which is manifestly not true. Luckily, we've
had people like Tor on the windows side and an assorted bunch of
people for os x that have done the work of making it work on other
platforms *anyway*. But even with such heroic efforts, there continue
to be things that are not quite the way they should be on non-X11
platforms, and depending on what your app does, these may be
completely ignorable or showstoppers.

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

Re: GTK+ 3, Win32 and GtkApplication (DBus woes)

[Tristan Van Berkom]

On Mon, Mar 28, 2011 at 8:26 PM, Kean Johnston kean.johns...@gmail.com wrote:
 On 3/28/2011 1:12 PM, Paul Davis wrote:

 On Mon, Mar 28, 2011 at 5:35 AM, Kean Johnstonkean.johns...@gmail.com
  wrote:

 Hello everyone,

 GtkApplication is a rather new piece of the GTK API. There has been
 quite a bit of discussion about its role and its impact on cross
 platform portability.

 I'll try read more of the mailing list archive. I have a vested interest in
 Gtk+ 3 on Win32 and MacOS, so if ever any help is needed or wanted testing
 any changes, I am very happy to help.

 The answer for now is that if you want cross platform portability,
 simply don't use GtkApplication. It didn't exist several months ago,
 and there are plenty of excellent apps written with GTK that don't use
 it.

 In one particular case, namely using the current beta of Glade, I was able
 to get it to at least start working by extracting a previous version of
 main.c from git. Fortunately, the change the author made to use
 GtkApplication was in a single commit so it was easy to unwind.

Yes I'm sorry about that. I innocently assumed it would be properly
portable as everything in GTK+ is portable, and there was no
proper notation that the application object was not available
on win32 or osx (like say, GtkUnixPrint widgets).

Anyway, I'll be backing out that commit from Glade.

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

Re: GTK+ 3, Win32 and GtkApplication (DBus woes)

[Kean Johnston]

Yes I'm sorry about that. I innocently assumed it would be properly
portable as everything in GTK+ is portable, and there was no
proper notation that the application object was not available
on win32 or osx (like say, GtkUnixPrint widgets).
For the most part it seems that GTK+'s portability holds true. The trouble 
is in layers beneath it, in this case Gio. I just came across another 
example of strangeness in Gio on Win32. On Windows it is much rarer to have 
things installed in a central location available to everyone to use, many 
applications will ship their own versions of the DLL's in their own private 
directories. This makes reliance on central-installed, compiled files like 
compiled schemas in Gio a problem on Windows.


Other underpinning layers like Pango can have the same problem if not 
compiled properly. For example, you *can* compile it to dynamically load in 
modules and that works really well on Linux but less well on Win32, where 
the modules tend to be built in.


Since I am new to this list I am unsure of the etiquette involved in 
discussing issues in integral underpinnings of GTK+ like Glib/Gio, and I 
know there's a fair amount of cross-pollination of developers, but if 
discussions of Glib/Gio issues, especially as related to GTK+ are unwelcome 
or unproductive here, I'll move my questions to the appropriate place, 
wherever that is.


Kean

PS thank you very much for Glade :) I have some patches for you to get it 
to compile with MSVC that I'll be sending you shortly.

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

Re: GtkApplication and argc/arv

[Colin Walters]

On Mon, Mar 21, 2011 at 6:03 AM, Murray Cumming murr...@murrayc.com wrote:

 I very much like the re-show-instead-of-reopening idea, and miss it
 since I stopped using MacOS 7.3. However, I don't understand why this
 should require a single process.

How do you recommend apps implement this then?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Petr Tomasek]

On Thu, Mar 10, 2011 at 09:01:51AM -0500, Morten Welinder wrote:
  What global state, for instance?
 
 locale?
 
 As a reminder, setlocale is not thread-safe.
 
 M.

Wait... So it won't be possible with gnome-shell/gtk3 applications
to have two instances of the same program started with two different
locales?

P.

-- 
Petr Tomasek http://www.etf.cuni.cz/~tomasek
Jabber: but...@jabbim.cz


EA 355:001  DU DU DU DU
EA 355:002  TU TU TU TU
EA 355:003  NU NU NU NU NU NU NU
EA 355:004  NA NA NA NA NA



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

Re: GtkApplication and argc/arv

[Colin Walters]

On Fri, Mar 25, 2011 at 12:39 PM, Petr Tomasek toma...@etf.cuni.cz wrote:

 Wait... So it won't be possible with gnome-shell/gtk3 applications
 to have two instances of the same program started with two different
 locales?

By default, yes, that is correct.  Application authors can do whatever
they want to support this if they think it's important.  I'm not
really convinced that running a whole different process is a sane
solution for GNumeric to do different decimal separators.  At some
point, you have to start fixing the underlying stack; so libc would
need to gain sprintf_locale (en_US.UTF-8, %f, 0.1) etc.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Matthias Clasen]

On Fri, Mar 25, 2011 at 1:08 PM, Colin Walters walt...@verbum.org wrote:
 On Fri, Mar 25, 2011 at 12:39 PM, Petr Tomasek toma...@etf.cuni.cz wrote:

 Wait... So it won't be possible with gnome-shell/gtk3 applications
 to have two instances of the same program started with two different
 locales?

 By default, yes, that is correct.  Application authors can do whatever
 they want to support this if they think it's important.  I'm not
 really convinced that running a whole different process is a sane
 solution for GNumeric to do different decimal separators.  At some
 point, you have to start fixing the underlying stack; so libc would
 need to gain sprintf_locale (en_US.UTF-8, %f, 0.1) etc.

http://www.manpagez.com/man/3/printf_l/

Unfortunately, never standardized, and only in bsd libcs...
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Murray Cumming]

On Sat, 2011-03-19 at 09:44 -0400, Colin Walters wrote:
 Hi Murray,
 
 On Sat, Mar 19, 2011 at 9:11 AM, Murray Cumming murr...@murrayc.com wrote:
 
  For this and other unrelated reasons, I will remove Gtk::Application
  from gtkmm 3.0.0. I can't wrap an API that I don't understand
 
 It's not that you don't understand it exactly, it's that you don't
 agree, correct?

No. I mean what I said and I'm getting rather tired of saying it. I
doubt that others here welcome my persistence either. And really, it's
too late for gtkmm 3.0 at this point. 

   I stated reasons above.

I disagree that reasons have been stated properly.

I guess that answers to these questions might help me:
http://mail.gnome.org/archives/gtk-devel-list/2011-March/msg00053.html
http://mail.gnome.org/archives/gtk-devel-list/2011-March/msg00043.html

 I just looked through my entire application list; and have only 2 out
 of ~50 which I think would obviously be fine as multiprocess (namely
 file-roller, evince).  The rest are games (about 15), system tools
 (abrt, selinux, ~10), apps like gedit which i know are single process
 (~10), etc.

Why wouldn't gedit be fine as multiprocess? Why wouldn't most
document-based applications be fine as multiprocess? Why wouldn't
gnome-terminal be fine as multiprocess?

I'm repeating myself, and I don't plan to do it much more, but I still
see no reason to encourage applications to be multi-process where there
is no shared data that is not already handled by multi-process APIs such
as GSettings.

 Obviously - for any app that desires multiple windows (which is
 actually only ~15 of my apps) you can do both.

You can't apparently do both easily with GtkApplication. If both are
considered valid by GTK+ then GtkApplication should have some clear
warning that it pushes one model only and that it shouldn't be used if
that model is not wanted.

   But again - the point
 is that single process is more efficient.

Efficient in terms of memory? Does it all hinge on that?

 Also - the single process approach makes it trivial to avoid data loss
 in the scenario where you open a file twice (i.e. right click on
 my-notes.txt to open in Abiword from nautilus, later forget you had
 it open and do it again), which is definitely a very compelling
 argument to me.  If it's not for you, well I don't know what to say.

I very much like the re-show-instead-of-reopening idea, and miss it
since I stopped using MacOS 7.3. However, I don't understand why this
should require a single process.


-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

Re: GtkApplication and argc/arv

[Murray Cumming]

On Thu, 2011-03-10 at 20:04 +0100, Murray Cumming wrote:
 But for applications that actually have some reason to have multiple
 windows (typically document-based applications) I still know of no
 reason why we would want to suggest that they should have all windows
 in
 one process. 

For this and other unrelated reasons, I will remove Gtk::Application
from gtkmm 3.0.0. I can't wrap an API that I don't understand and I
can't tell people to use that API if I can't say why they should. Things
are much better now thanks to Matthias' extra documentation, but
fundamental questions remain.

Hopefully we can figure things out and add it for gtkmm 3.2. This is the
gtkmm bug about it:
https://bugzilla.gnome.org/show_bug.cgi?id=637445#c17


-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

Re: GtkApplication and argc/arv

[Colin Walters]

Hi Murray,

On Sat, Mar 19, 2011 at 9:11 AM, Murray Cumming murr...@murrayc.com wrote:

 For this and other unrelated reasons, I will remove Gtk::Application
 from gtkmm 3.0.0. I can't wrap an API that I don't understand

It's not that you don't understand it exactly, it's that you don't
agree, correct?  I stated reasons above.

I just looked through my entire application list; and have only 2 out
of ~50 which I think would obviously be fine as multiprocess (namely
file-roller, evince).  The rest are games (about 15), system tools
(abrt, selinux, ~10), apps like gedit which i know are single process
(~10), etc.

Obviously - for any app that desires multiple windows (which is
actually only ~15 of my apps) you can do both.  But again - the point
is that single process is more efficient.

Also - the single process approach makes it trivial to avoid data loss
in the scenario where you open a file twice (i.e. right click on
my-notes.txt to open in Abiword from nautilus, later forget you had
it open and do it again), which is definitely a very compelling
argument to me.  If it's not for you, well I don't know what to say.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[jose.ali...@gmail.com]

Hi

On Thu, Mar 10, 2011 at 4:04 PM, Murray Cumming murr...@murrayc.com wrote:
 On Thu, 2011-03-10 at 18:41 +, Chris Vine wrote:
 On Thu, 10 Mar 2011 16:47:59 +0100
 Murray Cumming murr...@murrayc.com wrote:
  If it's most programs then surely you can give some example. I don't
  think that most applications have to deal with caching, bookmarks, and
  history like Firefox.

 I didn't realise you wanted examples, but most programs that have a
 shared resource would fall into this category. For example, my mail
 reader (claws), and most other mail readers for that matter apart from
 yours, evolution, which I think is server/database based, are single
 instance programs (as it happens I have seen complaints that, for any
 one user, evolution should be single instance). The messaging
 applications I am running, empathy and pidgin, are single instance
 programs. (Skype is an example of a poorly designed one which does
 start another instance but then complains about it and interferes with
 itself: it would have done better to get it right by itself.)
 [snip]

 Yes, these are applications that should be single instance because
 that's what is obviously best for the user and it's about useless extra
 windows showing the same thing rather than about any user awareness of
 processes.

 But for applications that actually have some reason to have multiple
 windows (typically document-based applications) I still know of no
 reason why we would want to suggest that they should have all windows in
 one process.

The only thing I can think of is in apps with tabs, like firefox,
chrome, gedit. In this case, you will want to have one instance so you
can detach one tab from one window and attach it to another window (I
am assuming that doing this without having only one instance could be
much much harder)...

Greets

José



 --
 murr...@murrayc.com
 www.murrayc.com
 www.openismus.com

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

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

Re: GtkApplication and argc/arv

[Chris Vine]

On Wed, 9 Mar 2011 08:16:44 +
Emmanuele Bassi eba...@gmail.com wrote:
 On 2011-03-08 at 22:16, Paul Davis wrote:
  On Tue, Mar 8, 2011 at 9:56 PM, Andrew Cowie
  and...@operationaldynamics.com wrote:
   On Tue, 2011-03-08 at 12:06 +0100, Murray Cumming wrote:
   I would very much like some reasoning to point people at when I
   tell them to use GtkApplication. I will not just hand-wave and
   say that people say it's good.
  
   GtkApplication is the GNOME 3.0 replacement for LibUnique, right?
   If so, then fine; the developer can choose whether the single
   instance pattern is appropriate for their application as before.
  
  this is part of the problem here. GtkApplication was originally
  floated as something a bit different than just what libunique did.
  it increasingly feels as if it has morphed into nothing but a
  repalcement for it. this may or may not be true, but that's
  certainly the impression that discussions about it are creating.
 
 no, GtkApplication isn't being morphed into libunique replacement -
 and I can say so as the maintainer of libunique.
 
 it just so happens that, for the desktop that is currently being
 targeted on the X11/Linux platform (i.e. GNOME 3), the default
 approach for applications is strongly adviced to be the
 single-instance one[0].
 
 then there are the actions, for remote control; the application as a
 service implementation; the startup notification control; the window
 ↔ application relationship; the main loop control tied to the
 application's lifetime; etc.

The case for having single-instance programs in most cases for
programs with a GUI interface seems self-evident to me, since most
GUI programs keep some running global state which would be extremely
tedious to synchronise between different processes.

However, the deficiency I have found in the past with respect to
implementing single instance programs using gtk+/gnome is the window
manager.  Usually in the circumstances I have described you want
gtk_window_present() to do what it says it does (for the remote dbus
callback to bring up the chosen main application window to the user),
but the window manager seems to do its best to sabotage all attempts to
do so.

Will gnome shell adopt a different strategy on this?  I certainly hope
so.

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

Re: GtkApplication and argc/arv

[Alexandre Mazari]

 However, the deficiency I have found in the past with respect to
 implementing single instance programs using gtk+/gnome is the window
 manager.  Usually in the circumstances I have described you want
 gtk_window_present() to do what it says it does (for the remote dbus
 callback to bring up the chosen main application window to the user),
 but the window manager seems to do its best to sabotage all attempts to
 do so.

I am pretty sure you should do the gtk_window_present in your primary instance
at one of your application's actions activation.
Actually, it would be nice if the activation callback could receive
the timestamp of
the event, so we can use _present_with_time.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Murray Cumming]

On Thu, 2011-03-10 at 09:59 +, Chris Vine wrote:
[snip]
 The case for having single-instance programs in most cases for
 programs with a GUI interface seems self-evident to me, since most
 GUI programs keep some running global state which would be extremely
 tedious to synchronise between different processes.
[snip]

What global state, for instance?

-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

Re: GtkApplication and argc/arv

[Morten Welinder]

 What global state, for instance?

locale?

As a reminder, setlocale is not thread-safe.

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

Re: GtkApplication and argc/arv

[Murray Cumming]

On Thu, 2011-03-10 at 09:01 -0500, Morten Welinder wrote:
  What global state, for instance?
 
 locale?
 
 As a reminder, setlocale is not thread-safe.

Sorry, I don't understand. Could you explain in more detail? Why would
two separate instances (separate processes) of the same app care if
setlocale is not thread safe?

-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

Re: GtkApplication and argc/arv

[Morten Welinder]

 Sorry, I don't understand. Could you explain in more detail?

If you need to run two different windows in two different locales, then
single-instance is not possible.  For Gnumeric this happens regularly
due to the world's decimal separator mess.

The reason you cannot do this in a single instance is that (a) setlocale
is not thread safe, and (b) libraries like gtk+ like to start their own
threads out of your control.

 Why would
 two separate instances (separate processes) of the same app care if
 setlocale is not thread safe?

They wouldn't.  I didn't mean to imply that.

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

Re: GtkApplication and argc/arv

[Chris Vine]

On Thu, 10 Mar 2011 14:48:12 +0100
Murray Cumming murr...@murrayc.com wrote:
 On Thu, 2011-03-10 at 09:59 +, Chris Vine wrote:
 [snip]
  The case for having single-instance programs in most cases for
  programs with a GUI interface seems self-evident to me, since most
  GUI programs keep some running global state which would be extremely
  tedious to synchronise between different processes.
 [snip]
 
 What global state, for instance?

Most programs will keep application-related data relevant to all
instances running which is not configuration data suitable for dconf nor
something for which you want to set up a formal database to deal with
change notification and resolution.

Apart from that, quite frankly it is I think what most users expect
for programs having only one main window. The principal problem at the
moment is gtk_window_present(): a user starts a program (she may have
forgotten it is already running if it is minimised or on a different
desktop) and gets presented with ... some odd blinking thing in the
panel if she is attentive enough to spot it at all.

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

Re: GtkApplication and argc/arv

[Murray Cumming]

On Thu, 2011-03-10 at 14:54 +, Chris Vine wrote:
 On Thu, 10 Mar 2011 14:48:12 +0100
 Murray Cumming murr...@murrayc.com wrote:
  On Thu, 2011-03-10 at 09:59 +, Chris Vine wrote:
  [snip]
   The case for having single-instance programs in most cases for
   programs with a GUI interface seems self-evident to me, since most
   GUI programs keep some running global state which would be extremely
   tedious to synchronise between different processes.
  [snip]
  
  What global state, for instance?
 
 Most programs will keep application-related data relevant to all
 instances running which is not configuration data suitable for dconf nor
 something for which you want to set up a formal database to deal with
 change notification and resolution.

If it's most programs then surely you can give some example. I don't
think that most applications have to deal with caching, bookmarks, and
history like Firefox.

I accept that _some_ would have some shared data, and they might choose 
to go single-process to make that easier. But it doesn't seem common enough 
to recommend it generally.

 Apart from that, quite frankly it is I think what most users expect
 for programs having only one main window.

Hopefully we don't expect users to have any idea of whether multiple
document windows are really in the same process. The Quit menu item
leaks this low-level concept so I thought we were generally trying to
avoid it.

Or do you mean some other sign that users would have that an application
is single-process, that they would miss if it was multiple-process?

  The principal problem at the
 moment is gtk_window_present(): a user starts a program (she may have
 forgotten it is already running if it is minimised or on a different
 desktop) and gets presented with ... some odd blinking thing in the
 panel if she is attentive enough to spot it at all.
 
 Chris

-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

Re: GtkApplication and argc/arv

[Paul Davis]

On Thu, Mar 10, 2011 at 10:47 AM, Murray Cumming murr...@murrayc.com wrote:

 If it's most programs then surely you can give some example. I don't
 think that most applications have to deal with caching, bookmarks, and
 history like Firefox.

i think that the kind of thing chris is referring to is something like
a program setting. suppose you open app FooBar2000 twice. in one
instance, you change the preference barffle to yesterday +
sin(90). in the other, you change it to jan 1st 1911 + arctan
(0.2291). what is the value of the app preference at that point in
time?

he might be referring to something else entirely, of course.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Murray Cumming]

On Thu, 2011-03-10 at 10:54 -0500, Paul Davis wrote:
 On Thu, Mar 10, 2011 at 10:47 AM, Murray Cumming murr...@murrayc.com wrote:
 
  If it's most programs then surely you can give some example. I don't
  think that most applications have to deal with caching, bookmarks, and
  history like Firefox.
 
 i think that the kind of thing chris is referring to is something like
 a program setting. suppose you open app FooBar2000 twice. in one
 instance, you change the preference barffle to yesterday +
 sin(90). in the other, you change it to jan 1st 1911 + arctan
 (0.2291). what is the value of the app preference at that point in
 time?
 
 he might be referring to something else entirely, of course.

But that's configuration data that is handled by GSettings or GConf,
surely?

-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

Re: GtkApplication and argc/arv

[Chris Vine]

On Thu, 10 Mar 2011 16:47:59 +0100
Murray Cumming murr...@murrayc.com wrote:
 If it's most programs then surely you can give some example. I don't
 think that most applications have to deal with caching, bookmarks, and
 history like Firefox.

I didn't realise you wanted examples, but most programs that have a
shared resource would fall into this category. For example, my mail
reader (claws), and most other mail readers for that matter apart from
yours, evolution, which I think is server/database based, are single
instance programs (as it happens I have seen complaints that, for any
one user, evolution should be single instance). The messaging
applications I am running, empathy and pidgin, are single instance
programs. (Skype is an example of a poorly designed one which does
start another instance but then complains about it and interferes with
itself: it would have done better to get it right by itself.)

Usually if you start more than one of these you have simply made a
mistake, having forgotten that the program is already running on, say,
another desktop, or it has been launched by mime type rather than by
explicit intention of the user. What you want is for the existing
instance to reappear.  I agree that for things that are simply document
editors like emacs, or viewers like eog, or word processors, one can
reasonably anticipate that the user doesn't give a damn, provided
preferences work correctly (and if more than one instance has opened
the same document, they don't interfere with each other), but that is a
relatively small sub-set of programs.

 I accept that _some_ would have some shared data, and they might
 choose to go single-process to make that easier. But it doesn't seem
 common enough to recommend it generally.

I don't think there is a need to recommend anything.  I suspect that
now that, with GtkApplication, you don't have to write your own dbus
stuff, as I had to do in the past, ease of implementation will
naturally lead to single instance designs. There may well be cases
of multi-document programs where for good reason the programmer decides
not to do it that way, say for address space isolation, provided that
one can reasonably anticipate that different instances will not
interfere with each other and that is programmatically attended to.

I think we should just agree to disagree.  I think this is also
starting to go a little off topic on this particular mailing list.

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

Re: GtkApplication and argc/arv

[Emmanuele Bassi]

On 2011-03-08 at 22:16, Paul Davis wrote:
 On Tue, Mar 8, 2011 at 9:56 PM, Andrew Cowie
 and...@operationaldynamics.com wrote:
  On Tue, 2011-03-08 at 12:06 +0100, Murray Cumming wrote:
  I would very much like some reasoning to point people at when I tell
  them to use GtkApplication. I will not just hand-wave and say that
  people say it's good.
 
  GtkApplication is the GNOME 3.0 replacement for LibUnique, right? If so,
  then fine; the developer can choose whether the single instance pattern
  is appropriate for their application as before.
 
 this is part of the problem here. GtkApplication was originally
 floated as something a bit different than just what libunique did.
 it increasingly feels as if it has morphed into nothing but a
 repalcement for it. this may or may not be true, but that's certainly
 the impression that discussions about it are creating.

no, GtkApplication isn't being morphed into libunique replacement -
and I can say so as the maintainer of libunique.

it just so happens that, for the desktop that is currently being
targeted on the X11/Linux platform (i.e. GNOME 3), the default approach
for applications is strongly adviced to be the single-instance one[0].

then there are the actions, for remote control; the application as a
service implementation; the startup notification control; the window ↔
application relationship; the main loop control tied to the
application's lifetime; etc.

as usual, if developers for other platforms want to be represented, they
have to show up.

ciao,
 Emmanuele.

[0] *strongly adviced* doesn't mean you can't do anything else, or else
  you'll receive a visit from a guy named Ramone and a 2-by-4; it means
  that you should probably follow the advice to get the best experience
  possible on that particular platform.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Murray Cumming]

On Thu, 2011-02-24 at 17:55 -0500, Colin Walters wrote:
 On Thu, Feb 24, 2011 at 5:15 PM, Morten Welinder mort...@gnome.org wrote:
 
  What actual problem was solved by all this infrastructure to keep just
  one instance?
 
 Basically for any application which manipulates private files in any
 form (in Firefox' case, this is the history database), it avoids data
 corruption with uncontrolled access by multiple processes.

This doesn't seem likely to be interesting to most apps. GSettings (or
GConf) handles shared access to the configuration data.

   It also
 matches the GNOME 3 experience; for any apps that can have multiple
 windows, it's usually far saner (and more efficient) to implement it
 with one process.
[snip]

Maybe I don't understand, but that sounds just like it's saner without
telling me why. Or are you talking about windows that are shared between
document windows, such as having 2 gimp images open with only one
toolbar window?

I would very much like some reasoning to point people at when I tell
them to use GtkApplication. I will not just hand-wave and say that
people say it's good.


-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

Re: GtkApplication and argc/arv

[Andrew Cowie]

On Tue, 2011-03-08 at 12:06 +0100, Murray Cumming wrote:
 I would very much like some reasoning to point people at when I tell
 them to use GtkApplication. I will not just hand-wave and say that
 people say it's good.

GtkApplication is the GNOME 3.0 replacement for LibUnique, right? If so,
then fine; the developer can choose whether the single instance pattern
is appropriate for their application as before.

I believe that's the deal, and I'm happy to include coverage for it, but
as Murray has asked, it would be really appreciated if a bit more detail
— aimed for people who haven't yet had an opportunity to be deeply
immersed yet in the GNOME 3.0 experience — about what matching that
experience means, and why you want us to encourage developers to create
single instance apps.

[I did see a bug or two about GtkApplication go by recently, so if this
has been addressed in forthcoming API documentation then thank you.
Still, discussion on the behaviour you're asking us to encourage would
be really helpful]

AfC
Sydney



signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Paul Davis]

On Tue, Mar 8, 2011 at 9:56 PM, Andrew Cowie
and...@operationaldynamics.com wrote:
 On Tue, 2011-03-08 at 12:06 +0100, Murray Cumming wrote:
 I would very much like some reasoning to point people at when I tell
 them to use GtkApplication. I will not just hand-wave and say that
 people say it's good.

 GtkApplication is the GNOME 3.0 replacement for LibUnique, right? If so,
 then fine; the developer can choose whether the single instance pattern
 is appropriate for their application as before.

this is part of the problem here. GtkApplication was originally
floated as something a bit different than just what libunique did.
it increasingly feels as if it has morphed into nothing but a
repalcement for it. this may or may not be true, but that's certainly
the impression that discussions about it are creating.

from my own perspective, i wanted GtkApplication to be something that
would ease the task of integrating my app into the desktop, whether
that desktop was a freedesktop implementation or quartz (or windows).
the functionality offered by libunique was (and is) of no interest to
me at all.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Murray Cumming]

On Fri, 2011-02-25 at 12:53 +0200, Claudio Saavedra wrote:
 On Fri, 2011-02-25 at 08:58 +0100, Carlos Garcia Campos wrote:
  Note that we moved from single process model to multiple process
  without changing the evince behaviour, it still behaves like a single
  instance app, opening an already opened document brings it to the
  front. 
 
 As far as I understand, you can achieve this with
 GApplication/GtkApplication by a combination of G_APPLICATION_IS_SERVICE
 and G_APPLICATION_IS_LAUNCHER in both a service and a launcher process.
[snip]

Is there any example of this in an application? It seems generally
useful.

I'd like to use GtkApplication for Glom but I don't want to make all
instances be in the same process, because:

1. It will crash.
2. I currently have a global object for application-wide stuff such as a
pointer to the main window. Being single-process lets me just use that
global instance from various parts of my code rather than passing it up
and down all the levels of code as an extra function parameter.

-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com


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

Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[Tristan Van Berkom]

On Sat, 2011-02-26 at 10:37 -0500, David Zeuthen wrote:
 Hey,
 
 On Sat, Feb 26, 2011 at 10:26 AM, Paul Davis p...@linuxaudiosystems.com 
 wrote:
  On Sat, Feb 26, 2011 at 10:00 AM, David Zeuthen zeut...@gmail.com wrote:
  Hi,
 
  Just for the record, there's no reason that GDBus cannot be made to
  work very nicely on Win32 or any other platform we care about. GDBus
  (and D-Bus itself) was designed with this goal in mind.
 
  what functionality is (G)D-Bus supposed to be providing on other
  platforms? my impression has been that on linux it provides stuff that
  both OS X and Windows already provides (plus or minus a detail or
  two). if that impression is correct, why would anyone run (G)D-Bus on
  those platforms? if its not correct, what is the functionality that
  (G)D-Bus is offering to linux that is missing from those platforms? if
  you're talking about just a portable API to interact with various
  system services and notifications, then fine, but that's a bit
  different than talking about D-Bus itself, i think.
 
 Yes, on the free desktop we use D-Bus a lot in system services
 (udisks, upower etc.) and in the sessions to implement the desktop
 itself (notifications, session management etc.) - neither of which
 (portable) apps should use. Instead apps should use the interfaces in
 GLib/GTK+.
 
 For example, instead of speaking to udisks directly, the app should
 use GVolumeMonitor which on Linux uses udisks and on Win32 uses the
 native APIs. Ditto for pretty much everything else.
 
  just to be clear: i'm a big fan of the functionality that D-Bus  (at
  least the system bus and maybe the session bus too) has made possible
  on linux. i just don't understand why anyone would imagine using it on
  other platforms.
 
 One place where D-Bus is useful is for an app to provide a remote
 control interface so e.g. 3rd party apps can control it / interact
 with it. The app just says: use interface org.App.Bar on object
 /org/App/bar on the name org.App.FooApp on the session bus.
 
 But, yeah, D-Bus isn't all that useful for apps as is it to build an
 OS... I'd argue it would still be nice to have GDBus working *out of
 the box* in Win32 and OS X. Someone just need to do the work - it's
 already 99% done...

Guys, maybe someone here can answer my question.

Does an application that uses GtkApplication work on win32/osx ?

I'm not asking for a full implementation of dbus on every platform
and I'm also not asking for a proper GApplicationImpl for every
platform.

If a glib/gtk+ application uses GtkApplication, what I expect is
that if there is no IPC backend available for that platform,
the application loses some of it's facilities and just work without
any backend present (i.e. the application is not registered on any
bus, the application is not single instance, but at least it fires 
up and silently succeeds).

Nobody on irc seems able to answer this question for me, and from
reading the sources I can see that

 - gapplicationimpl-dbus.c seems to be compiled into gio regardless
   of the platform

 - gapplication.c seems to just call g_application_impl_register()
   and g_application_run() seems to just return a failure status
   if g_application_impl_register() happens to return NULL.

Again, I'm not asking for someone to do the work of implementing it
properly on win32 or osx, but if GApplication simply fails just because
there is no backend then it's not portable at all and either needs to
be advertized as such or it's a serious bug.

FWIW, I ported Glade to use GtkApplication following my blind trust that
if the API is in GTK+, it will at least do something reasonable on any
platform GTK+ compiles on... do I have to pull out that change while
GApplication is still unstable ?

Best Regards,
   -Tristan


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

Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[Matthias Clasen]

On Mon, Mar 7, 2011 at 1:22 AM, Tristan Van Berkom
trista...@openismus.com wrote:
 On Sat, 2011-02-26 at 10:37 -0500, David Zeuthen wrote:


 ... do I have to pull out that change while
 GApplication is still unstable ?

GApplication is not unstable.

It is true that after all the back-and-forth, nobody has gotten around
to writing a non-dbus backend.

It shares that fate with many other features, like file monitoring,
content types, etc. where  native implementations on other platforms
are sadly missing.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[Tristan Van Berkom]

On Mon, 2011-03-07 at 16:08 -0500, Matthias Clasen wrote:
 On Mon, Mar 7, 2011 at 1:22 AM, Tristan Van Berkom
 trista...@openismus.com wrote:
  On Sat, 2011-02-26 at 10:37 -0500, David Zeuthen wrote:
 
 
  ... do I have to pull out that change while
  GApplication is still unstable ?
 
 GApplication is not unstable.
 
 It is true that after all the back-and-forth, nobody has gotten around
 to writing a non-dbus backend.
 

Ok but regardless of what's there and what's missing, this still does
not answer my question.

Will use of GtkApplication cause my app to simply fail just because
a win32/osx implementation is missing ? or will it silently succeed ?

And I think we need to be very clear here about what is supported
on all platforms and what is not, being a cross-platform toolkit
is probably still GTK+'s leading selling points.

There are different levels of supported on different platforms,
for instance it is very clear that GtkUnixPrint widgets are
only available on x11, so you dont compile it for win32 or quartz.

If GTK+ lets you compile it for win32 or another platform, it should
be safe to call the APIs from that platform, even if it doesn't work.

For instance, a query of content-types on win32, if not implemented
can return no results... if it causes your program to abort() on win32
just because a public cross-platform API is unimplemented... that *is*
indeed unstable if you ask me.

As I mentioned before, I'm not asking for an implementation on win32
of GtkApplication, I'm just asking for it to succeed, run a mainloop
and do something as a fallback for a missing implementation.

a.) GtkApplication only available as GtkX11Application is acceptable,
 because people only expect it to work on x11 (the actual stubs
 should in this case only be created on x11 and the docs should
 mention that it an x11-only object).

b.) GtkApplication as a public and clearly cross-platform API that
 has a fallback that runs the main loop is acceptable, win32
 apps that adopt early will benefit from single instance and
 other details once the win32 backend for GtkApplication is
 created.

c.) GtkApplication that is public and causes your application
 to simply fail just because of a missing backend, is just
 broken (and I think that's what happens now but I dont have
 a win32 machine to try it on).

So where do we stand ? If we are falling into case c.) then it's
simply a bug (and yes, I would say it's a serious bug, enough to
say the api is unstable and likely to cause your app to fail
under certain weather conditions) the application should just work 
on other platforms without implementing any of the dbus features.

 It shares that fate with many other features, like file monitoring,
 content types, etc. where  native implementations on other platforms
 are sadly missing.

Do we really have other instances like this ?

I mean, how do file monitoring apis and content type apis fail
under win32/osx ?

I suspect that we have either... a function that lists content
types which simply returns no results... that does not break a
program as far as I can see.

Or a GInitable object that is created for a file and has a
signal to tell you when the monitored file has changed ?

Again not such a problem, people are supposed to check
the return values of initable objects and deal with the
fact that they could not get a GFileMonitor this time.

If there are other cases of public apis that cause 
multi-platform apps to actually break directly, we should 
fix the bugs as a priority, people expect at least this
much from glib/gtk+.

Regards,
-Tristan


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

Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[Matthias Clasen]

On Mon, Mar 7, 2011 at 4:40 AM, Tristan Van Berkom
trista...@openismus.com wrote:


 As I mentioned before, I'm not asking for an implementation on win32
 of GtkApplication, I'm just asking for it to succeed, run a mainloop
 and do something as a fallback for a missing implementation.

So, you are not asking for an implementation, you just want it to work
? :-) Thats kinda funny...

 It shares that fate with many other features, like file monitoring,
 content types, etc. where  native implementations on other platforms
 are sadly missing.

 Do we really have other instances like this ?

Here is some analysis of portability concerns for the GNOME stack, not
just GTK+. Might be instructive:

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

Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[Paul Davis]

On Mon, Mar 7, 2011 at 4:40 AM, Tristan Van Berkom
trista...@openismus.com wrote:

 a.) GtkApplication only available as GtkX11Application is acceptable,
     because people only expect it to work on x11 (the actual stubs
     should in this case only be created on x11 and the docs should
     mention that it an x11-only object).

 b.) GtkApplication as a public and clearly cross-platform API that
     has a fallback that runs the main loop is acceptable, win32
     apps that adopt early will benefit from single instance and
     other details once the win32 backend for GtkApplication is
     created.

for quartz, there are a specific set of interactions with launch
services that would be very desirable to have integrated into
GtkApplication. right now, these are implemented in an add-on code
blob (ige-mac-menu), and/or as additional code in specific
applications. it would be sad to give up on the idea of these being
subsumed into GtkApplication. there is likely other integration with
the os x desktop that could be usefully done too.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[Tristan Van Berkom]

On Mon, 2011-03-07 at 16:48 -0500, Matthias Clasen wrote:
 On Mon, Mar 7, 2011 at 4:40 AM, Tristan Van Berkom
 trista...@openismus.com wrote:
 
 
  As I mentioned before, I'm not asking for an implementation on win32
  of GtkApplication, I'm just asking for it to succeed, run a mainloop
  and do something as a fallback for a missing implementation.
 
 So, you are not asking for an implementation, you just want it to work
 ? :-) Thats kinda funny...

Sure it sounds funny. however it's all together reasonable.

All that needs to be done for a backend using object
like GApplication is something like this:

int
g_application_run (...)
{
   backend = create_backend ();

   if (backend)
  return backend-run()

   /* Fallback to no IPC, take care not to cause
* the calling application to explode
*/   

   /* make sure we call the GApplication vfuncs properly,
* Call the initializer first 
*/
   this.init_or_activate_or_whatever_it_is();

   /* If it handles the command line, give it the arguments */
   this.local_command_line ()

   /* run GTK+ */
   gtk_main();
}

How simple is that ?

I'm not asking for exporting actions on some kind of bus api,
if the backend is missing, obviously you cant get activated
for any reason by any bus.

Not asking for built-in application uniqueness either.

Just run the main loop... everything that is unsupported
will just not happen, it would at least be *safe* to
use the GApplication.

From where I stand, you just can't use GApplication at
all for a cross-platform app... I did not read that anywhere
in the docs, and running a GApplication on win32 will actually
cause the application to not start up.

How is this an unreasonable expectation of glib ?

How can you call it stable if it fails on various
supported platforms ?

Regards,
   -Tristan

 
  It shares that fate with many other features, like file monitoring,
  content types, etc. where  native implementations on other platforms
  are sadly missing.
 
  Do we really have other instances like this ?
 
 Here is some analysis of portability concerns for the GNOME stack, not
 just GTK+. Might be instructive:
 
 https://live.gnome.org/PortabilityMatrix


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

Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[Emmanuele Bassi]

On 2011-03-07 at 18:40, Tristan Van Berkom wrote:
 Will use of GtkApplication cause my app to simply fail just because
 a win32/osx implementation is missing ? or will it silently succeed ?

there is nothing X11-specific in GApplication or GtkApplication.

in fact, if you install D-Bus on OSX or Windows, GApplication will work
just as fine as on Linux.

what's missing is a non-DBus IPC mechanism for platforms that have a
system IPC API.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[Tristan Van Berkom]

On Mon, 2011-03-07 at 22:52 +, Emmanuele Bassi wrote:
 On 2011-03-07 at 18:40, Tristan Van Berkom wrote:
  Will use of GtkApplication cause my app to simply fail just because
  a win32/osx implementation is missing ? or will it silently succeed ?
 
 there is nothing X11-specific in GApplication or GtkApplication.
 
 in fact, if you install D-Bus on OSX or Windows, GApplication will work
 just as fine as on Linux.
 
 what's missing is a non-DBus IPC mechanism for platforms that have a
 system IPC API.

Sure, but if there is no dbus, running a GtkApplication should surely
at least run the GTK+ main loop.

If GTK+ passes the configure script on any supported platform, running
a gapplication should, IMO, at least run the main loop.

What we have now is a situation with absolutely no fallback at all,
so people have to write:

#if HAVE_DBUS

... use GtkApplication ...

#else

.. initialize everything and call gtk_main()

#endif

So a cross-platform app cannot use GtkApplication without itself
installing it's own custom made fallbacks and only conditionally
using GtkApplication.

I'm sorry but I *expect* these fallbacks to be in
GApplication/GtkApplication, that's what I expect from
this thing we call a multi-platform toolkit... I expect
to not have to write '#ifdef WIN32' in my code, and
when I go ahead and use an object from glib/gtk+, I expect
it to be safe, compile, run and at least do it's best
on every supported platform.

Things like gtk_window_set_decorated() are documented as
it might not work, depends on your window manager, however
those things do not deny you from creating a GtkWindow when
using sawfish.

Features of GtkApplication such as application uniqueness
and actions exported over the bus should be documented
as action will only be exported on a bus if dbus or
another backend is available on your system or such.

Those conditions should not result on g_application_run()
simply not running the mainloop and returning just because
it cannot do IPC.

  a.) It's a high expectation and GTK+ has until now, to
  my knowledge always fulfilled this expectation.

  b.) It's damn easy to make GApplication at least startup
  correctly, run the main loop and just not use any IPC, 
  it's the least I think that one can expect.

So can we at least concede that GApplication should have
a fallback and at least be usable on a system with no IPC ?
(even, say.. a linux system with no dbus installed ?).

Regards,
 -Tristan


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

Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[Matthias Clasen]

On Mon, Mar 7, 2011 at 6:17 AM, Tristan Van Berkom
trista...@openismus.com wrote:

  b.) It's damn easy to make GApplication at least startup
      correctly, run the main loop and just not use any IPC,
      it's the least I think that one can expect.

Then lets the patch already, instead of needlessly prolonging this
thread even further...
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[Alberto Ruiz]

2011/3/7 Matthias Clasen matthias.cla...@gmail.com:
 On Mon, Mar 7, 2011 at 6:17 AM, Tristan Van Berkom
 trista...@openismus.com wrote:

  b.) It's damn easy to make GApplication at least startup
      correctly, run the main loop and just not use any IPC,
      it's the least I think that one can expect.

 Then lets the patch already, instead of needlessly prolonging this
 thread even further...

+1

-- 
Un saludo,
Alberto Ruiz
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Murray Cumming]

On Thu, 2011-02-24 at 23:41 +, Emmanuele Bassi wrote:
 On 2011-02-21 at 21:57, Murray Cumming wrote:
 
 I'll leave the other points, as they've received a reply already.
 
  2.
  How should we use GOptionContext to parse command line arguments from
  argc/argv when using GtkApplication. Is this the ideal way, using the
  command-line signal?
http://git.gnome.org/browse/totem/tree/src/totem.c#n187
  It seems a little long-winded.
 
 Totem's usage is not entirely trivial: it requires argument parsing in
 the local (i.e. the just executed) and remote (i.e. the currently
 running) instances.
 
 simpler cases are:
 
   • you can just parse all arguments in the local instance, which means
 using g_option_context_parse() prior to creating the G(tk)Application
 instance; in this case, the command line arguments can be used to
 parametrize the Application instance, e.g via GObject properties,
 direct access to instance members, or even GApplication actions (as
 soon as they get more functionality).
 
   • you can defer all command line parsing to the remote instance, by
 passing the G_APPLICATION_HANDLES_COMMAND_LINE flag to the
 constructor and by connecting to the ::command-line signal; and
 example is in the Dictionary:
 
 
 http://git.gnome.org/browse/gnome-utils/tree/gnome-dictionary/src/gdict-app.c#n222
 
 probably the latter case is a more direct map of what you'd have done
 with libunique or the Bacon copy-and-paste API.
 
 in general, and if at all possible, I'd strongly advise to use the first
 approach (local parsing), and keep an eye out as soon as the GAction API
 gets more love and functionality.

Thanks for the suggestion, but why wouldn't you use the
GApplication::local_command_line vfunc for local command-line parsing?
http://library.gnome.org/devel/gio/unstable/GApplication.html#GApplicationClass.local-command-line


-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

Re: GtkApplication and argc/arv

[Alexandre Mazari]

On Wed, Mar 2, 2011 at 9:30 AM, Murray Cumming murr...@murrayc.com wrote:
 On Thu, 2011-02-24 at 23:41 +, Emmanuele Bassi wrote:
 On 2011-02-21 at 21:57, Murray Cumming wrote:

 I'll leave the other points, as they've received a reply already.

  2.
  How should we use GOptionContext to parse command line arguments from
  argc/argv when using GtkApplication. Is this the ideal way, using the
  command-line signal?
    http://git.gnome.org/browse/totem/tree/src/totem.c#n187
  It seems a little long-winded.

 Totem's usage is not entirely trivial: it requires argument parsing in
 the local (i.e. the just executed) and remote (i.e. the currently
 running) instances.

 simpler cases are:

   • you can just parse all arguments in the local instance, which means
     using g_option_context_parse() prior to creating the G(tk)Application
     instance; in this case, the command line arguments can be used to
     parametrize the Application instance, e.g via GObject properties,
     direct access to instance members, or even GApplication actions (as
     soon as they get more functionality).

   • you can defer all command line parsing to the remote instance, by
     passing the G_APPLICATION_HANDLES_COMMAND_LINE flag to the
     constructor and by connecting to the ::command-line signal; and
     example is in the Dictionary:

     
 http://git.gnome.org/browse/gnome-utils/tree/gnome-dictionary/src/gdict-app.c#n222

 probably the latter case is a more direct map of what you'd have done
 with libunique or the Bacon copy-and-paste API.

Just be aware that you should generate a new GOptionContext at each
parsing. I tried to keep one around for performance reason and soon
discovered that GOption is not really reentrant (use of global targets
variables and GOptionGroup hooks abused as init entry point by libs).
Next pass, I'd probably do the parsing in each secondary instances and
communicate to the primary using open and customs action.


 in general, and if at all possible, I'd strongly advise to use the first
 approach (local parsing), and keep an eye out as soon as the GAction API
 gets more love and functionality.

 Thanks for the suggestion, but why wouldn't you use the
 GApplication::local_command_line vfunc for local command-line parsing?
 http://library.gnome.org/devel/gio/unstable/GApplication.html#GApplicationClass.local-command-line


 --
 murr...@murrayc.com
 www.murrayc.com
 www.openismus.com

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




-- 
If you open your mind too much, you brain will fall out
Tim Minchin
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Emmanuele Bassi]

On 2011-03-02 at 09:30, Murray Cumming wrote:
• you can defer all command line parsing to the remote instance, by
  passing the G_APPLICATION_HANDLES_COMMAND_LINE flag to the
  constructor and by connecting to the ::command-line signal; and
  example is in the Dictionary:
  
  
  http://git.gnome.org/browse/gnome-utils/tree/gnome-dictionary/src/gdict-app.c#n222
 
 Thanks for the suggestion, but why wouldn't you use the
 GApplication::local_command_line vfunc for local command-line parsing?
 http://library.gnome.org/devel/gio/unstable/GApplication.html#GApplicationClass.local-command-line

if I a) don't want to sub-class GApplication and b) want to do local
command line parsing, it's pretty trivial to use a GOptionContext and
parse the command line prior to creating the GApplication. the only
difference between that and using local_command_line() is that with the
former you can create an Application instance with its initial state
already set up from the command line arguments parsing; and with the
latter you have access to an already existing Application instance that
you can change.

again: if you're pattern is to sub-class GApplication then
local_command_line() is probably a better choice; but we don't strictly
require sub-classing in gio and gtk+.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Murray Cumming]

On Wed, 2011-03-02 at 10:07 +, Emmanuele Bassi wrote:
[snip]
  Thanks for the suggestion, but why wouldn't you use the
  GApplication::local_command_line vfunc for local command-line parsing?
  http://library.gnome.org/devel/gio/unstable/GApplication.html#GApplicationClass.local-command-line
 
 if I a) don't want to sub-class GApplication and b) want to do local
 command line parsing, it's pretty trivial to use a GOptionContext and
 parse the command line prior to creating the GApplication.
[snip]

That would be nice for us to recommend here,
  https://bugzilla.gnome.org/show_bug.cgi?id=643650
but wouldn't that require us to call gtk_init() before
g_option_context_parse(), to first remove the standard options? Or we
could just call gtk_init_with_args().

Then I guess we could pass NULL, NULL to g_application_run() for
argc/argv, but this is one of the things that needs to be documented:
  https://bugzilla.gnome.org/show_bug.cgi?id=643649


-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

Re: GtkApplication and argc/arv

[Emmanuele Bassi]

On 2011-03-03 at 07:18, Murray Cumming wrote:
 On Wed, 2011-03-02 at 10:07 +, Emmanuele Bassi wrote:
 [snip]
   Thanks for the suggestion, but why wouldn't you use the
   GApplication::local_command_line vfunc for local command-line parsing?
   http://library.gnome.org/devel/gio/unstable/GApplication.html#GApplicationClass.local-command-line
  
  if I a) don't want to sub-class GApplication and b) want to do local
  command line parsing, it's pretty trivial to use a GOptionContext and
  parse the command line prior to creating the GApplication.
 [snip]
 
 That would be nice for us to recommend here,
   https://bugzilla.gnome.org/show_bug.cgi?id=643650
 but wouldn't that require us to call gtk_init() before
 g_option_context_parse(), to first remove the standard options? Or we
 could just call gtk_init_with_args().

you can get the option group from GTK+/GDK, and even do so without
opening the GdkDisplay; these will take care of the GTK+/GDK command
line options (while they are still there).

there are least three or four different ways (and probably more that I
just don't see) of doing command line argument parsing with GOption and
GApplication; the examples in the GIO documentation and tests/ directory
are a demonstration.

there's also the matter that GOption was written way before GApplication,
and the API of GOption is constrained by its location insize GLib. I
wouldn't be surprised if at any point in time we just added some command
line option parsing API into GApplication itself.

ciao,
 Emmanuele.

-- 
W: http://www.emmanuelebassi.name
B: http://blogs.gnome.org/ebassi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[David Zeuthen]

Hey,

On Fri, Feb 25, 2011 at 2:28 PM, Havoc Pennington h...@pobox.com wrote:
 So upstream's advice is, don't restart, because apps won't handle it.

 If you want to fix all the apps, you can do so. There are no
 dbus-daemon changes required.

If you really wanted to handle the dbus package got upgraded, let's
switch to running the new code asap use-case (which is the core thing
people want to do), I think a nicer solution is to make dbus-daemon(1)
exec(2) a new copy of itself passing all state (including fds with
existing connections) to the new copy. I think init(1) does that. Of
course, this is nasty business, you have to establish and maintain a
stable restart-protocol...

Of course this doesn't handle the case where dbus-daemon(1) segfaults
but the other solution (handle restarts in apps) doesn't cover more
interesting cases like dbus-daemon(1) hanging or otherwise
malfunctioning.

Either way, I personally think the whole problem is a gigantic waste
of time to discuss so I usually avoid discussing it ... for me, it's
totally a non-issue if you just accept that the Core OS is more than
just code running in ring 0 and that we don't support this for the OS
kernel either (yes, we all know about ksplice, no need to bring it
up). So when people complain I tell them to write that dbus-daemon(1)
patch if they want and that usually makes them go away.

 (fwiw, g_bus_own_name() in gdbus could in theory make it considerably
 easier to handle bus restart, assuming gdbus itself handles it.)

Early versions of the gdbus code actually did that... but it made the
code a lot more complex than it needed to be (resubmitting match
rules, invalidating assumptions about the unique name being constant
etc. etc.)... then I decided that the issue can (and I think, should)
be fixed in the dbus-daemon(1) if you really want to... I, for one,
don't care - but if someone writes a nice dbus-daemon(1) patch, we
would probably accept it, right?

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

GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[David Zeuthen]

Hi,

Just for the record, there's no reason that GDBus cannot be made to
work very nicely on Win32 or any other platform we care about. GDBus
(and D-Bus itself) was designed with this goal in mind.

That is to say, it is possible to make a Win32 build of GLib where
GDBus works as expect in both peer-to-peer mode (this already works,
GDBus supports e.g. the nonce-tcp: transport) and in session bus mode
(including autospawning the bus if necessary and talking to other apps
etc.)

FWIW, the latter clearly includes shipping a copy of dbus-daemon.exe
along with the GLib libraries which you already need to ship as part
of your app. It also includes D-Bus spec work to find the address of
the bus - right now this is *undocumented* (that is,
http://dbus.freedesktop.org/doc/dbus-specification.html does not
mention how) but I had this working at some point, see

 
http://cgit.freedesktop.org/~david/gdbus-standalone/commit/?id=44c8871c5c27337dc1905a0b4c9d35d46eb2144a
 http://people.freedesktop.org/~david/gdbus-win32.png

If someone wants to work on this, I'd recommend

1. Get the missing pieces into the spec (the DBusAutolaunchMutex and
DBusDaemonMutex stuff).

2. Make dbus-launch --autolaunch=machine_id --binary-syntax
--close-stderr a supported and official D-Bus interface - because
with this 3rd party D-Bus implementations (like GDBus) can simply use
that to launch the message bus (e.g. not have to care about where to
get the bus address, be it in the X server, the Windows registry, OS
X's launch or whatever). Note: on the free desktop we actually rely on
this to work

 http://git.gnome.org/browse/glib/tree/gio/gdbusaddress.c?id=2.28.0#n1012

3. Ship dbus-daemon.exe and dbus-launch.exe (and possibly other bits
from the dbus-1 package) along with the GLib libraries on Win32 (and
ditto on OS X)

Bottom line: D-Bus support can (relatively easily) be made to work on
all the platforms that we care about in GLib and GTK+. Which means
that it's actually fine to have a *hard* dependency on D-Bus in
GApplication if we wanted. Of course it's a lot easier to not use
D-Bus because in reality Win32 and OS X resources in the GLib and
D-Bus projects are just not there. And for other reasons, it's
probably better to use native frameworks for application uniqueness
*anyway* - for example, on Win 7 you want to use the native APIs for
better shell integration.

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

Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[Paul Davis]

On Sat, Feb 26, 2011 at 10:00 AM, David Zeuthen zeut...@gmail.com wrote:
 Hi,

 Just for the record, there's no reason that GDBus cannot be made to
 work very nicely on Win32 or any other platform we care about. GDBus
 (and D-Bus itself) was designed with this goal in mind.

what functionality is (G)D-Bus supposed to be providing on other
platforms? my impression has been that on linux it provides stuff that
both OS X and Windows already provides (plus or minus a detail or
two). if that impression is correct, why would anyone run (G)D-Bus on
those platforms? if its not correct, what is the functionality that
(G)D-Bus is offering to linux that is missing from those platforms? if
you're talking about just a portable API to interact with various
system services and notifications, then fine, but that's a bit
different than talking about D-Bus itself, i think.

just to be clear: i'm a big fan of the functionality that D-Bus  (at
least the system bus and maybe the session bus too) has made possible
on linux. i just don't understand why anyone would imagine using it on
other platforms.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GDBus support on Win32 + other platforms (Was Re: GtkApplication and argc/arv)

[David Zeuthen]

Hey,

On Sat, Feb 26, 2011 at 10:26 AM, Paul Davis p...@linuxaudiosystems.com wrote:
 On Sat, Feb 26, 2011 at 10:00 AM, David Zeuthen zeut...@gmail.com wrote:
 Hi,

 Just for the record, there's no reason that GDBus cannot be made to
 work very nicely on Win32 or any other platform we care about. GDBus
 (and D-Bus itself) was designed with this goal in mind.

 what functionality is (G)D-Bus supposed to be providing on other
 platforms? my impression has been that on linux it provides stuff that
 both OS X and Windows already provides (plus or minus a detail or
 two). if that impression is correct, why would anyone run (G)D-Bus on
 those platforms? if its not correct, what is the functionality that
 (G)D-Bus is offering to linux that is missing from those platforms? if
 you're talking about just a portable API to interact with various
 system services and notifications, then fine, but that's a bit
 different than talking about D-Bus itself, i think.

Yes, on the free desktop we use D-Bus a lot in system services
(udisks, upower etc.) and in the sessions to implement the desktop
itself (notifications, session management etc.) - neither of which
(portable) apps should use. Instead apps should use the interfaces in
GLib/GTK+.

For example, instead of speaking to udisks directly, the app should
use GVolumeMonitor which on Linux uses udisks and on Win32 uses the
native APIs. Ditto for pretty much everything else.

 just to be clear: i'm a big fan of the functionality that D-Bus  (at
 least the system bus and maybe the session bus too) has made possible
 on linux. i just don't understand why anyone would imagine using it on
 other platforms.

One place where D-Bus is useful is for an app to provide a remote
control interface so e.g. 3rd party apps can control it / interact
with it. The app just says: use interface org.App.Bar on object
/org/App/bar on the name org.App.FooApp on the session bus.

But, yeah, D-Bus isn't all that useful for apps as is it to build an
OS... I'd argue it would still be nice to have GDBus working *out of
the box* in Win32 and OS X. Someone just need to do the work - it's
already 99% done...

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

Re: GtkApplication and argc/arv

[Carlos Garcia Campos]

Excerpts from Tristan Van Berkom's message of vie feb 25 00:52:21 +0100 2011:
 On Fri, Feb 25, 2011 at 8:25 AM, jose.ali...@gmail.com
 jose.ali...@gmail.com wrote:
  Hi,
 
  On Tue, Feb 22, 2011 at 6:45 AM, Murray Cumming murr...@murrayc.com wrote:
  On Mon, 2011-02-21 at 21:57 +0100, Murray Cumming wrote:
  I'm trying to wrap GtkApplication for gtkmm but I can't really do that
  until I understand how it's meant to be used.
 
  In general, I find the documentation lacks overview and advice, partly
  because it's spread between GApplication and GtkApplication and mentions
  some concepts without explaining them first. So I have some questions.
 
  1.
  Are we still meant to call gtk_init(argc, argv) when using
  GtkApplication, which takes argc/argv again via g_application_run(). Or
  is gtk_init() then superfluous?
 
  Mathias mentioned that gtk_init(NULL, NULL) is best anyway, though I
  don't understand why:
    http://bugzilla.gnome.org/show_bug.cgi?id=639925#c3
 
  2.
  How should we use GOptionContext to parse command line arguments from
  argc/argv when using GtkApplication. Is this the ideal way, using the
  command-line signal?
    http://git.gnome.org/browse/totem/tree/src/totem.c#n187
  It seems a little long-winded.
 
  And more simply:
 
  3. Will we recommend that all GTK+ applications generally use
  GtkApplication?
 
  4. Do we believe that all (GTK+) applications should be single-instance
  applications?
 
  Just to point out  an example, Evince does not use GtkApplication and
  it's not single instanced (there is one process per each document you
  see) and I don't think there are plans to make it single instanced.
 
 Right,
   however as I mentioned it would not hurt evince if it was a single
 instance, we would save on memory and gain in startup time for every
 document that evince is invoked for, without harming evince in any way.

We think that robustness is more important than using more memory or
taking a bit longer to start (I would like to see the numbers that
proof that, since we changed from single process to multi-process
nobody has filed a bug report about evince consuming more memory or
being slower at startup). Evince depends on external libraries to
render pdf, ps, etc. and it's easy to make those libs crash with buggy
documents. So, unless GtkApplication allows us to keep our current
multi-process model, still behaving as a single-instance app, we are
not going to migrate.

 Furthermore using GtkApplication everywhere opens up the door for
 more sophisticated integration that could hypothetically happen
 in the future.
 
   - it would allow for system watchdogs to be implemented without any explicit
 cooperation on the part of the application for one,
 
   - it could serve to provide some basic system messaging for the
 desktop and applications, like updating the input method for all
 running applications, or even changing the desktop locale and
 retranslating messages (albeit runtime translation switching would
 of course require more api, but GtkLabel for instance could be
 given a translatable format and retranslate itself automatically whenever
 the desktop language changes...).
 
 I'm not saying that everybody should hurry up and do extra work they dont
 need to... however I do think having a unified GtkApplication api with as many
 apps using it as possible seems to be a step in the right direction (whether
 its the GNOME Shell that communicates with the GtkApplication, or
 MyCustomHandPhoneShell that uses it... having a well defined/unified
 api for this stuff seems like a good thing to have).
 

Regards, 
-- 
Carlos Garcia Campos
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x523E6462


signature.asc
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Murray Cumming]

On Thu, 2011-02-24 at 17:51 -0500, Colin Walters wrote:
  1.
  Are we still meant to call gtk_init(argc, argv) when using
  GtkApplication, which takes argc/argv again via g_application_run(). Or
  is gtk_init() then superfluous?
 
 gtk_init is superfluous, yes;

I guess we should mention GtkApplication here then:
http://library.gnome.org/devel/gtk3/stable/gtk3-General.html#gtk-init

  it's handled in the startup phase of
 GtkApplication.

Do you mean, during g_application_run(), or earlier?

  Mathias mentioned that gtk_init(NULL, NULL) is best anyway, though I
  don't understand why:
   http://bugzilla.gnome.org/show_bug.cgi?id=639925#c3
 
 It doesn't really do anything interesting or useful; you can achieve 
 everything
 with environment variables

But don't (bearded) people expect applications to take (GNU?) standard
command line options, such as --display=DISPLAY?

If we really think people should do this:
  gtk_init(NULL, NULL),
or
  g_application_run(NULL, NULL),
then surely we should say so in the documentation. I don't like the
vagueness right now.

The documentation currently doesn't even say that NULLs are valid
values:
http://library.gnome.org/devel/gtk3/stable/gtk3-General.html#gtk-init
http://library.gnome.org/devel/gio/unstable/GApplication.html#g-application-run


-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

Re: GtkApplication and argc/arv

[Claudio Saavedra]

On Fri, 2011-02-25 at 08:58 +0100, Carlos Garcia Campos wrote:
 
  
  Just to point out  an example, Evince does not use GtkApplication 
  and it's not single instanced (there is one process per each
  document you see) and I don't think there are plans to make it 
  single instanced.
 
 Note that we moved from single process model to multiple process
 without changing the evince behaviour, it still behaves like a single
 instance app, opening an already opened document brings it to the
 front. 

As far as I understand, you can achieve this with
GApplication/GtkApplication by a combination of G_APPLICATION_IS_SERVICE
and G_APPLICATION_IS_LAUNCHER in both a service and a launcher process.

Admittedly, the GApplication examples and documentation are not crystal
clear about all the possibilities it brings, so it's not a big surprise
that people are reluctant to get to know it and use it. Not
everyone wants to dig into totem or other application's code to get to
understand how things are supposed to be done. 

Claudio



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

Re: GtkApplication and argc/arv

[Bastien Nocera]

On Thu, 2011-02-24 at 17:51 -0500, Colin Walters wrote:
 On Mon, Feb 21, 2011 at 3:57 PM, Murray Cumming murr...@murrayc.com wrote:
snip
  2.
  How should we use GOptionContext to parse command line arguments from
  argc/argv when using GtkApplication. Is this the ideal way, using the
  command-line signal?
   http://git.gnome.org/browse/totem/tree/src/totem.c#n187
  It seems a little long-winded.
 
 I think that's best practice, yeah.  It's obviously complicated, but I
 don't think it could really be made much easier.  Be happy to be
 proved wrong though =)

Totem's use of GtkApplication is broken actually. It doesn't parse
command-line arguments properly on the client side (so --version won't
work if you have a running instance).

The problem is that Totem doesn't just want to show up a window, and
then process the arguments. We want to know whether the user asked for
fullscreen on startup, before showing the window for example.

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

Re: GtkApplication and argc/arv

[Morten Welinder]

On Thu, Feb 24, 2011 at 5:55 PM, Colin Walters walt...@verbum.org wrote:
 On Thu, Feb 24, 2011 at 5:15 PM, Morten Welinder mort...@gnome.org wrote:

 What actual problem was solved by all this infrastructure to keep just
 one instance?

 Basically for any application which manipulates private files in any
 form (in Firefox' case, this is the history database), it avoids data
 corruption with uncontrolled access by multiple processes.

That's an excellent reason for making single-process available, but not
an argument (either way) for making it the default.  It certainly doesn't
sound like a problem experienced by, say, evince.

What is the GtkApplication solution to dealing with different environment
variables, including DISPLAY and LANG?

I believe the single/multiple instances is a decision for the developer and
not one Gnome or Gtk should have an opinion on.

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

Re: GtkApplication and argc/arv

[Matthias Clasen]

On Thu, Feb 24, 2011 at 8:51 PM, Wen-Yen Chuang ca...@calno.com wrote:

 Because dbus is slow and unreliable.

Starting with this premise is not going to be very useful... D-Bus is
generally considered a good thing here.

 We have other speedy and reliable IPC to be used for single instance
 apps. Why I have to use dbus just because I use GTK+ at the same time?

You don't. Nobody forces you to use GtkApplication.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Havoc Pennington]

Hi,

On Thu, Feb 24, 2011 at 8:51 PM, Wen-Yen Chuang ca...@calno.com wrote:
 a.) restart dbus daemon (and keep everything communicating to dbus
    still working) is not supported by upstream in a sensible way.
    [1][2][3][4]

upstream doesn't support this because it isn't a dbus issue. The
problem is that no apps handle restart.

So upstream's advice is, don't restart, because apps won't handle it.

If you want to fix all the apps, you can do so. There are no
dbus-daemon changes required.

(fwiw, g_bus_own_name() in gdbus could in theory make it considerably
easier to handle bus restart, assuming gdbus itself handles it.)

The reason apps don't handle it is because this is a very hard thing
to handle and requires per-app work. You'd have the same problem with
any stateful IPC protocol. (You can build stateless protocols on dbus
if you like, that will have no issue.)

Anyway, the upstream position, or at least my opinion, with respect to
the system bus, is restarting won't work in practice because you
can't rely on apps handling it rather than apps should not handle
it. If apps handle it that's great.

The links you mention are just a bunch of confused people blaming the
protocol, when the issue is the missing logic in apps.

With respect to the session bus, the bus exiting is supposed to end
the session, so in that case exiting has special meaning and apps
should not try to survive it. The same is true of gnome-session for
example.

But still, that is a case of policy decision for what apps do, and has
nothing to do with dbus-daemon or the dbus protocol.

 b.) dbus can not be used over network
    You have to setup a proxy for dbus to use it over network.

You can enable TCP if you have shared network homedirs and it ought to
work. If you don't have shared homedirs you would have to add support
for another auth method, something that nobody has done yet, but
anyone is certainly welcome. For some applications, you may also be
able to use anonymous auth (i.e. no-auth mode).

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

Re: GtkApplication and argc/arv

[Havoc Pennington]

Hi,

On Fri, Feb 25, 2011 at 9:13 PM, Wen-Yen Chuang ca...@calno.com wrote:

 I suppose GtkApplication users do not need to handle dbus directly.

 So if GtkApplication can handle dbus restart / dbus crash, I may also
 consider using GtkApplication for single instance app.

However, the whole restart issue and those debian discussions you
linked to don't really apply to GtkApplication, because it uses the
session rather than the system bus, as far as I know.

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

Re: GtkApplication and argc/arv

[Tristan Van Berkom]

On Thu, 2011-02-24 at 13:11 +0800, Wen-Yen Chuang wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 02/24/11 08:41, Tristan Van Berkom wrote:
  As far as I know, GtkApplication depends on GIO, which
  should have some extension points for services on different
  operating systems... using dbus on linux (not exactly sure
  how this works currently in GIO but that's what I suspect
  is going on).
 
 If GtkApplication can use socket or other non-dbus IPC on linux,
 I have nothing against it.
 
 However, I failed to find options/conffiles/environment variables to
 use GtkApplication without dbus on linux. :-(
 

Why do you care what GTK+ uses if you dont have to deal with the
dbus apis yourself anyway ?

Or are you putting together a distro for your embedded device
with limited resources and want to run many GTK+ applications
and use gsettings etc without using dbus for some performance
reason ?

afaik, dbus is the desktops IPC future, sounds like a better
idea to send patches and improve it than to just hate it.

  Not sure here either... on the one hand, many apps do not need
  to be single instance... and on the other hand... for apps that do not
  really need to be single instance apps; it does not hurt if they are
  implemented as single instance apps.
 
 It do not hurt, but is not convenient sometimes.
 
 a.) Testing newly-built/new version of libraries and applications
 
 b.) Running multiple versions of the same application
   For example, running firefox 3.5, 3.6, and 4.0 at the same time.

Hmmm a  b are kind of the same, either way they are not important
for end users that receive stable software that works (but I 
guess that if GtkApplication does not have a --start-me-up-separately
command line argument already, adding one will still make sense for
this).

 c.) For stability
   Crash of one process will not affect other processes.

Eh, ok... I don't really agree but the fact is you might sell
that to a manager somewhere who wants to ship his unstable software
early and say it doesnt crash at least most of the time, or
when it crashes only one window crashes so its ok to sell it
to users.

 
 There are many other reasons to not use single instance.

I think it would be constructive for you to list them here.

 If GtkApplication can not turn off single instance,
 I will not use it when I do not need single instance.

*if* GtkApplication does not yet support a command line
option for starting up a separate instance for testing
purposes or whatever... I'm sure someone (someone like you)
will add that command line option in the form of a patch.

I'm also quite sure that if that patch does not break
anything it will be accepted and applied 

(for instance many people use gedit and test new versions 
of gedit simultaneously, so you want to be sure when running
a relocated build in a prefix it doesnt just communicate
with the already running gedit and give you a new window
every time you test something).

Remember, GTK+ is a community project and it only improves
when people like you, who have nitpicks and find problems
with the api _actually take the time to improve it_.

Cheers,
 -Tristan


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

Re: GtkApplication and argc/arv

[Christian Hergert]

On Thu, 2011-02-24 at 13:11 +0800, Wen-Yen Chuang wrote:
 
 b.) Running multiple versions of the same application
 For example, running firefox 3.5, 3.6, and 4.0 at the same
 time. 

I don't think your example actually works without running each instance
using a different firefox user profile. I don't see using a different
application-id in gtk_applicaion_new() fundamentally different than
having multiple user profiles for each concurrent version of firefox.

-- Christian

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

Re: GtkApplication and argc/arv

[Morten Welinder]

 There are many other reasons to not use single instance.

I agree.

d. Running on a different $DISPLAY.  Look and you'll find no end of
complaints over firefox' inability to do this sanely.

e. Running with different locale settings.  This happens for Gnumeric
when people want different decimal separator for different files.

f. Limiting what documents script see.

 If GtkApplication can not turn off single instance,
 I will not use it when I do not need single instance.

Ditto.  Or I'll create an id like gnumeric-$PID

What actual problem was solved by all this infrastructure to keep just
one instance?

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

Re: GtkApplication and argc/arv

[Colin Walters]

On Mon, Feb 21, 2011 at 3:57 PM, Murray Cumming murr...@murrayc.com wrote:
 I'm trying to wrap GtkApplication for gtkmm but I can't really do that
 until I understand how it's meant to be used.

 In general, I find the documentation lacks overview and advice, partly
 because it's spread between GApplication and GtkApplication and mentions
 some concepts without explaining them first.

Yeah, it's an issue.

 1.
 Are we still meant to call gtk_init(argc, argv) when using
 GtkApplication, which takes argc/argv again via g_application_run(). Or
 is gtk_init() then superfluous?

gtk_init is superfluous, yes; it's handled in the startup phase of
GtkApplication.

 Mathias mentioned that gtk_init(NULL, NULL) is best anyway, though I
 don't understand why:
  http://bugzilla.gnome.org/show_bug.cgi?id=639925#c3

It doesn't really do anything interesting or useful; you can achieve everything
with environment variables

 2.
 How should we use GOptionContext to parse command line arguments from
 argc/argv when using GtkApplication. Is this the ideal way, using the
 command-line signal?
  http://git.gnome.org/browse/totem/tree/src/totem.c#n187
 It seems a little long-winded.

I think that's best practice, yeah.  It's obviously complicated, but I
don't think it could really be made much easier.  Be happy to be
proved wrong though =)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Colin Walters]

On Thu, Feb 24, 2011 at 5:15 PM, Morten Welinder mort...@gnome.org wrote:

 What actual problem was solved by all this infrastructure to keep just
 one instance?

Basically for any application which manipulates private files in any
form (in Firefox' case, this is the history database), it avoids data
corruption with uncontrolled access by multiple processes.  It also
matches the GNOME 3 experience; for any apps that can have multiple
windows, it's usually far saner (and more efficient) to implement it
with one process.

As for things like a developer scenario where you want to disable it
temporarily for whatever reason, sure - we could add
G_DEBUG=disable-single-instance or something?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Tristan Van Berkom]

On Fri, Feb 25, 2011 at 8:25 AM, jose.ali...@gmail.com
jose.ali...@gmail.com wrote:
 Hi,

 On Tue, Feb 22, 2011 at 6:45 AM, Murray Cumming murr...@murrayc.com wrote:
 On Mon, 2011-02-21 at 21:57 +0100, Murray Cumming wrote:
 I'm trying to wrap GtkApplication for gtkmm but I can't really do that
 until I understand how it's meant to be used.

 In general, I find the documentation lacks overview and advice, partly
 because it's spread between GApplication and GtkApplication and mentions
 some concepts without explaining them first. So I have some questions.

 1.
 Are we still meant to call gtk_init(argc, argv) when using
 GtkApplication, which takes argc/argv again via g_application_run(). Or
 is gtk_init() then superfluous?

 Mathias mentioned that gtk_init(NULL, NULL) is best anyway, though I
 don't understand why:
   http://bugzilla.gnome.org/show_bug.cgi?id=639925#c3

 2.
 How should we use GOptionContext to parse command line arguments from
 argc/argv when using GtkApplication. Is this the ideal way, using the
 command-line signal?
   http://git.gnome.org/browse/totem/tree/src/totem.c#n187
 It seems a little long-winded.

 And more simply:

 3. Will we recommend that all GTK+ applications generally use
 GtkApplication?

 4. Do we believe that all (GTK+) applications should be single-instance
 applications?

 Just to point out  an example, Evince does not use GtkApplication and
 it's not single instanced (there is one process per each document you
 see) and I don't think there are plans to make it single instanced.

Right,
  however as I mentioned it would not hurt evince if it was a single
instance, we would save on memory and gain in startup time for every
document that evince is invoked for, without harming evince in any way.

Furthermore using GtkApplication everywhere opens up the door for
more sophisticated integration that could hypothetically happen
in the future.

  - it would allow for system watchdogs to be implemented without any explicit
cooperation on the part of the application for one,

  - it could serve to provide some basic system messaging for the
desktop and applications, like updating the input method for all
running applications, or even changing the desktop locale and
retranslating messages (albeit runtime translation switching would
of course require more api, but GtkLabel for instance could be
given a translatable format and retranslate itself automatically whenever
the desktop language changes...).

I'm not saying that everybody should hurry up and do extra work they dont
need to... however I do think having a unified GtkApplication api with as many
apps using it as possible seems to be a step in the right direction (whether
its the GNOME Shell that communicates with the GtkApplication, or
MyCustomHandPhoneShell that uses it... having a well defined/unified
api for this stuff seems like a good thing to have).

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

Re: GtkApplication and argc/arv

[Wen-Yen Chuang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/24/11 10:58, Tristan Van Berkom wrote:
 Why do you care what GTK+ uses if you dont have to deal with the
 dbus apis yourself anyway ?

Because dbus is slow and unreliable.
a.) restart dbus daemon (and keep everything communicating to dbus
still working) is not supported by upstream in a sensible way.
[1][2][3][4]
b.) dbus can not be used over network
You have to setup a proxy for dbus to use it over network.

[1] http://kitenet.net/~joey/blog/entry/dbus_reconnection/
[2] https://bbs.archlinux.org/viewtopic.php?id=76353
[3] http://bugs.debian.org/495257
[4] http://bugs.debian.org/573386

We have other speedy and reliable IPC to be used for single instance
apps. Why I have to use dbus just because I use GTK+ at the same time?

This topic is started by Murray Cumming because he is trying to wrap
GtkApplication for gtkmm. Why we force all gtkmm users to use dbus?

As I have said, I have nothing against GtkApplication, I just do not
want to us dbus.

 afaik, dbus is the desktops IPC future, sounds like a better
 idea to send patches and improve it than to just hate it.

How can you improve dbus when it is designed to not support restart and
over network?

 c.) For stability
  Crash of one process will not affect other processes.
 
 Eh, ok... I don't really agree but the fact is you might sell
 that to a manager somewhere who wants to ship his unstable software
 early and say it doesnt crash at least most of the time, or
 when it crashes only one window crashes so its ok to sell it
 to users.

Crash is not always due to internal bug or unstable software.
a.) inadequate resources
For example, you open a really large file in an editor.
The editor freeze and you want to kill it, but the editor
still has other windows opened.
b.) dbus restart / dbus crashes
Congratulation! Your well-written, bug-free single instance app
crashes.
c.) killed by user

I like single instance. I have said it is good in my first reply.
I just do not want everything to be single instance.

Kind regards
 Wen-Yen Chuang (caleb)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1nCyUACgkQdEpXpumNYVlWLwCgg+lItcV8e27eDB1K6aqhPNOn
lXUAn34W4DaMgb6w5pJUiqtN00eduySV
=etXK
-END PGP SIGNATURE-
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Wen-Yen Chuang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Murray Cumming wrote:
 3. Will we recommend that all GTK+ applications generally use
 GtkApplication?

As far as I know, GtkApplication depends on dbus.
You can not use GtkApplication without dbus.
(Please correct me if I am wrong.)
So, I think the answer is No.
I personal hates dbus and do not use it.

 4. Do we believe that all (GTK+) applications should be
 single-instance applications?

Single-instance application is good, but not everything should be
single-instance.
So again, I think the answer is No.

Kind regards
 Wen-Yen Chuang (caleb)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1ke8AACgkQdEpXpumNYVkwNwCfYfZ+3ah+BkzrCNQHLZC1bgBL
6QMAn2Px2HZtcQaht4f5O3DXjg5LKuz/
=KGRW
-END PGP SIGNATURE-
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Tristan Van Berkom]

On Wed, Feb 23, 2011 at 12:15 PM, Wen-Yen Chuang ca...@calno.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Murray Cumming wrote:
 3. Will we recommend that all GTK+ applications generally use
 GtkApplication?

 As far as I know, GtkApplication depends on dbus.
 You can not use GtkApplication without dbus.
 (Please correct me if I am wrong.)
 So, I think the answer is No.
 I personal hates dbus and do not use it.

I think and hope this is besides the point, GtkApplication
should be portable for all the relevant GTK+ targets, otherwise
I made a big mistake making Glade a GtkApplication.

As far as I know, GtkApplication depends on GIO, which
should have some extension points for services on different
operating systems... using dbus on linux (not exactly sure
how this works currently in GIO but that's what I suspect
is going on).

In the worst case, if the GIO extension points needed for GtkApplication
are missing on a given system, then possibly your app loses
it's power to be single instance. In any case, using GtkApplication
does not mean you have a direct dependency on a library that
might not be installed and it's a severe GTK+ bug IMO if your app
stops working on win32 or osx just because you are using
GtkApplication.

 4. Do we believe that all (GTK+) applications should be
 single-instance applications?

 Single-instance application is good, but not everything should be
 single-instance.
 So again, I think the answer is No.

Not sure here either... on the one hand, many apps do not need
to be single instance... and on the other hand... for apps that do not
really need to be single instance apps; it does not hurt if they are
implemented as single instance apps.

However there are some advantages if all apps are GtkApplication:

  a.) Overall less memory consumption

A single instance app that just creates a new window for every
time that
it is invoked does not allocate memory for any copy-on-write data from
the GTK+ library nor does it allocate any extra memory on the heap for
the widget classes and the type system (this applies not only to GTK+
but for any libraries that the said app might link against).

  b.) A small gain in application startup time

Along the same lines as a.), an application might only have
to initialize
some things once at startup time but not again for every consecutive
invocation.

  c.) Another gain if every app was a GtkApplication is that we define a common
   api for launching programs... this opens up some new doors.

   This kind of initiative could eventually help for implementing
watchdogs and
   doing things like changing the current locale of an already
running application
   (I'm thinking of the IPhone's springboard here, still some
obvious gaps that
   need bridging in the meego platform).

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

Re: GtkApplication and argc/arv

[Wen-Yen Chuang]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/24/11 08:41, Tristan Van Berkom wrote:
 As far as I know, GtkApplication depends on GIO, which
 should have some extension points for services on different
 operating systems... using dbus on linux (not exactly sure
 how this works currently in GIO but that's what I suspect
 is going on).

If GtkApplication can use socket or other non-dbus IPC on linux,
I have nothing against it.

However, I failed to find options/conffiles/environment variables to
use GtkApplication without dbus on linux. :-(

 Not sure here either... on the one hand, many apps do not need
 to be single instance... and on the other hand... for apps that do not
 really need to be single instance apps; it does not hurt if they are
 implemented as single instance apps.

It do not hurt, but is not convenient sometimes.

a.) Testing newly-built/new version of libraries and applications

b.) Running multiple versions of the same application
For example, running firefox 3.5, 3.6, and 4.0 at the same time.

c.) For stability
Crash of one process will not affect other processes.

There are many other reasons to not use single instance.

If GtkApplication can not turn off single instance,
I will not use it when I do not need single instance.

Kind regards
 Wen-Yen Chuang (caleb)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1l6GYACgkQdEpXpumNYVmVBgCgibhb9DEfWncoxPEVWgdx7zPr
jVkAnjvPP4w/14V202sKlkuJOIeVHym7
=tI+l
-END PGP SIGNATURE-
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkApplication and argc/arv

[Murray Cumming]

On Mon, 2011-02-21 at 21:57 +0100, Murray Cumming wrote:
 I'm trying to wrap GtkApplication for gtkmm but I can't really do that
 until I understand how it's meant to be used.
 
 In general, I find the documentation lacks overview and advice, partly
 because it's spread between GApplication and GtkApplication and mentions
 some concepts without explaining them first. So I have some questions.
 
 1.
 Are we still meant to call gtk_init(argc, argv) when using
 GtkApplication, which takes argc/argv again via g_application_run(). Or
 is gtk_init() then superfluous?
 
 Mathias mentioned that gtk_init(NULL, NULL) is best anyway, though I
 don't understand why:
   http://bugzilla.gnome.org/show_bug.cgi?id=639925#c3
 
 2.
 How should we use GOptionContext to parse command line arguments from
 argc/argv when using GtkApplication. Is this the ideal way, using the
 command-line signal?
   http://git.gnome.org/browse/totem/tree/src/totem.c#n187
 It seems a little long-winded.

And more simply:

3. Will we recommend that all GTK+ applications generally use
GtkApplication?

4. Do we believe that all (GTK+) applications should be single-instance
applications?

-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

GtkApplication and argc/arv

[Murray Cumming]

I'm trying to wrap GtkApplication for gtkmm but I can't really do that
until I understand how it's meant to be used.

In general, I find the documentation lacks overview and advice, partly
because it's spread between GApplication and GtkApplication and mentions
some concepts without explaining them first. So I have some questions.

1.
Are we still meant to call gtk_init(argc, argv) when using
GtkApplication, which takes argc/argv again via g_application_run(). Or
is gtk_init() then superfluous?

Mathias mentioned that gtk_init(NULL, NULL) is best anyway, though I
don't understand why:
  http://bugzilla.gnome.org/show_bug.cgi?id=639925#c3

2.
How should we use GOptionContext to parse command line arguments from
argc/argv when using GtkApplication. Is this the ideal way, using the
command-line signal?
  http://git.gnome.org/browse/totem/tree/src/totem.c#n187
It seems a little long-winded.


-- 
murr...@murrayc.com
www.murrayc.com
www.openismus.com

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

GtkApplication handling command line

[Jonh Wendell]

hi, folks. I'm trying to port vinagre from old gtkapplication to the new
implementation, based on totem code. there's an issue (totem is affected
too).

if I create the app object with HANDLE_COMMAND_LINE flag, the command
line will always be passed to the primary instance.

We (totem, vinagre and others) are using GOptionContext to parse command
line arguments. So, if the user has already totem running, open a
terminal and type 'totem --help', this will be passed to the primary
instance, which will output the help and exit the program.

Try yourself by running totem master. The code is here:
http://git.gnome.org/browse/totem/tree/src/totem.c

so, what should we do to handle this case? We want to parse things like
'--help' locally, but the rest we want to pass to the primary instance -
and we want to use GOptionContext.

Perhaps we can do something by subclassing gtkapplication and
overwriting local_command_line method, and do some workaround to still
be able to use GOptionContext both local and remotely.

As this is a typical use case in gnome applications, we should have a
better/easier way to integrate gtkapplication and goptioncontext, agree?

cheers,
-- 
Jonh Wendell
http://www.bani.com.br

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

Re: GtkApplication handling command line

[Bastien Nocera]

On Sat, 2010-11-13 at 10:22 -0300, Jonh Wendell wrote:
 hi, folks. I'm trying to port vinagre from old gtkapplication to the new
 implementation, based on totem code. there's an issue (totem is affected
 too).
 
 if I create the app object with HANDLE_COMMAND_LINE flag, the command
 line will always be passed to the primary instance.
 
 We (totem, vinagre and others) are using GOptionContext to parse command
 line arguments. So, if the user has already totem running, open a
 terminal and type 'totem --help', this will be passed to the primary
 instance, which will output the help and exit the program.

Do _NOT_ use Totem as an example of how to use GtkApplication. Totem is
special because it wants to parse the command-line, do some things, then
act some more on the command-line. And depending on the options, it
might, or might not have shown the window (because we want the window to
show up as soon as possible, unless we fullscreen it on startup).

 Try yourself by running totem master. The code is here:
 http://git.gnome.org/browse/totem/tree/src/totem.c
 
 so, what should we do to handle this case? We want to parse things like
 '--help' locally, but the rest we want to pass to the primary instance -
 and we want to use GOptionContext.
 
 Perhaps we can do something by subclassing gtkapplication and
 overwriting local_command_line method, and do some workaround to still
 be able to use GOptionContext both local and remotely.

You can already do that. Just parse the options in your handler for the
command-line signal, and voila.

 As this is a typical use case in gnome applications, we should have a
 better/easier way to integrate gtkapplication and goptioncontext, agree?

Cheers

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

Re: Can I get a quick overview of GtkApplication actions?

[Matthias Clasen]

On Fri, Oct 29, 2010 at 7:03 PM, Sandy Armstrong
sanfordarmstr...@gmail.com wrote:
 Howdy,

 I wasn't sure what list to email, so apologies if this is the wrong
 place to ask.

 I've heard some rumblings about the new GtkApplication having the
 ability to export actions in such a way that other apps can easily
 find and invoke those actions.  But the docs in GApplication and
 GtkApplication seem a bit short on details.

 Can anybody explain to me (or link me to an explanation) of what this
 feature is and how it works, and how it's expected to be used in (for
 example) gnome-shell?  Are the actions discoverable even when the app
 is not running?

 This could tie really nicely into some work I'd like to do to bring
 Windows 7 Jumplist-like functionality to GNOME, but I want to make
 sure I understand exactly what's currently implemented or planned to
 be implemented.

Hey, I've added a (very simple-minded) example of gapplication +
actions in the glib 2.27.2 docs. Should show up on library.gnome.org
soon.

As for jump lists and that kind of thing, Ryan is planning to land
some more exciting support in glib 2.28 / gtk3, which I assume he will
unveil sometime soon.


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

Re: Can I get a quick overview of GtkApplication actions?

[Matthias Clasen]

On Mon, Nov 1, 2010 at 2:22 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:

 Hey, I've added a (very simple-minded) example of gapplication +
 actions in the glib 2.27.2 docs. Should show up on library.gnome.org
 soon.

In fact, here it is:
http://library.gnome.org/devel/gio/2.27/GApplication.html#gapplication-example-actions
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Can I get a quick overview of GtkApplication actions?

[Havoc Pennington]

Hi,

On Mon, Nov 1, 2010 at 2:25 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:

 In fact, here it is:
 http://library.gnome.org/devel/gio/2.27/GApplication.html#gapplication-example-actions

Was a bit confused reading this example, what are the hold/release in
the action callbacks about? Would they only be needed if someone runs
the main loop in the callback?

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

Re: Can I get a quick overview of GtkApplication actions?

[Matthias Clasen]

On Mon, Nov 1, 2010 at 2:36 PM, Havoc Pennington h...@pobox.com wrote:
 Hi,

 On Mon, Nov 1, 2010 at 2:25 PM, Matthias Clasen
 matthias.cla...@gmail.com wrote:

 In fact, here it is:
 http://library.gnome.org/devel/gio/2.27/GApplication.html#gapplication-example-actions

 Was a bit confused reading this example, what are the hold/release in
 the action callbacks about? Would they only be needed if someone runs
 the main loop in the callback?

Yes, they are a little pointless here, and probably deserve a comment.

The idea is that the callback might open a new window, in which case
you want the application to stay around until that is closed again.
But gtk_window_set_application() takes care of that for you.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list