New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adjust the `Shoes says...` text in popups #59

Closed
ccoupe opened this Issue Feb 11, 2015 · 34 comments

Comments

Projects
None yet
3 participants
@ccoupe
Contributor

ccoupe commented Feb 11, 2015

The Shoes 4 folks are discussing the "Shoes says.." in alerts.
shoes/shoes4#1056 (comment)

@ccoupe ccoupe added the Enhancement label Feb 11, 2015

@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Feb 11, 2015

Collaborator

This would be a good change as far as deployment goes.

For the record in our own issue tracker:

Shoes.app {
   alert("Issue #59 in action")
}

image

Collaborator

BackOrder commented Feb 11, 2015

This would be a good change as far as deployment goes.

For the record in our own issue tracker:

Shoes.app {
   alert("Issue #59 in action")
}

image

@passenger94

This comment has been minimized.

Show comment
Hide comment
@passenger94

passenger94 Feb 13, 2015

Contributor

taking opportunity to dig into wild life :
adding in shoes/native.h

VALUE shoes_dialog_alert2(VALUE, VALUE, VALUE);

adding in shoes/ruby.c

rb_define_method(rb_mKernel, "alert2", CASTHOOK(shoes_dialog_alert2), 2);

adding in shoes/native/gtk.c

VALUE
shoes_dialog_alert2(VALUE self, VALUE says, VALUE msg)
{
  GLOBAL_APP(app);
  msg = shoes_native_to_s(msg);
  says = shoes_native_to_s(says);
  GtkWidget *dialog = gtk_message_dialog_new_with_markup(
    APP_WINDOW(app), GTK_DIALOG_MODAL,
    GTK_MESSAGE_INFO, GTK_BUTTONS_OK, "<span size='larger'>%s</span>\n\n%s",
    RSTRING_PTR(says), RSTRING_PTR(msg));
  gtk_dialog_run(GTK_DIALOG(dialog));
  gtk_widget_destroy(dialog);
  return Qnil;
}

so this works on ubuntu (really not sure i'm not breaking protocols !! )

# encoding: utf-8
Shoes.app(:title => "Shoes Events", :width => 450, :height => 250) {
   button("alert2") { alert2("Custom title â é ! ", "alert message") }
}

should be easy to add similar code in windows.c ..... with some quick help
cocoa.m needs more knowledge ... (creating a variable, making it safe, utf8 ???, etc...)

Contributor

passenger94 commented Feb 13, 2015

taking opportunity to dig into wild life :
adding in shoes/native.h

VALUE shoes_dialog_alert2(VALUE, VALUE, VALUE);

adding in shoes/ruby.c

rb_define_method(rb_mKernel, "alert2", CASTHOOK(shoes_dialog_alert2), 2);

adding in shoes/native/gtk.c

VALUE
shoes_dialog_alert2(VALUE self, VALUE says, VALUE msg)
{
  GLOBAL_APP(app);
  msg = shoes_native_to_s(msg);
  says = shoes_native_to_s(says);
  GtkWidget *dialog = gtk_message_dialog_new_with_markup(
    APP_WINDOW(app), GTK_DIALOG_MODAL,
    GTK_MESSAGE_INFO, GTK_BUTTONS_OK, "<span size='larger'>%s</span>\n\n%s",
    RSTRING_PTR(says), RSTRING_PTR(msg));
  gtk_dialog_run(GTK_DIALOG(dialog));
  gtk_widget_destroy(dialog);
  return Qnil;
}

so this works on ubuntu (really not sure i'm not breaking protocols !! )

# encoding: utf-8
Shoes.app(:title => "Shoes Events", :width => 450, :height => 250) {
   button("alert2") { alert2("Custom title â é ! ", "alert message") }
}

should be easy to add similar code in windows.c ..... with some quick help
cocoa.m needs more knowledge ... (creating a variable, making it safe, utf8 ???, etc...)

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 13, 2015

Contributor

@passenger94 Nice to know you're willing to dig into C and Gtk. The only protocol problem would be to commit and push an incomplete implementation.

I see two solutions. (1) replace the global dialog_title string - we'd need a method on Shoes.App? cocoa.m doesn't use that global so that's a complication.

or (2) add an optional argument to alert("Problem found", :app_title => "MyApp says") which is what Tobias was leaning towards on Shoes4. :app_tiltle is just an example symbol -- I'm sure a better name can be found. Without the option, alert would use the current global var (or strings in cocoa.m).

Contributor

ccoupe commented Feb 13, 2015

@passenger94 Nice to know you're willing to dig into C and Gtk. The only protocol problem would be to commit and push an incomplete implementation.

I see two solutions. (1) replace the global dialog_title string - we'd need a method on Shoes.App? cocoa.m doesn't use that global so that's a complication.

or (2) add an optional argument to alert("Problem found", :app_title => "MyApp says") which is what Tobias was leaning towards on Shoes4. :app_tiltle is just an example symbol -- I'm sure a better name can be found. Without the option, alert would use the current global var (or strings in cocoa.m).

@passenger94

This comment has been minimized.

Show comment
Hide comment
@passenger94

passenger94 Feb 13, 2015

Contributor

hello @ccoupe :)
i sort of took the second route, because of the cocoa difference.
solution might be easy with some C knowledge, at least with adding a simple second argument like here in gtk.c, doing the same in windows.c is just a matter of giving the right kind of "string" to the function, in cocoa maybe just creating an appropriate variable and giving it "toalertWithMessageText:" (??)
if involving an optional hash variable to shoes_dialog_alert ... i need ... some more digging :-D

i think i need to work with stuff like

shoes_dialog_alert2(int argc, VALUE *argv, VALUE self)
rb_arg_list args;
rb_parse_args(argc, argv, "s|h", &args); what would be the right param here instead of "s|h"

might not have enough time in very near future to get a good basic understanding of this :-(

Contributor

passenger94 commented Feb 13, 2015

hello @ccoupe :)
i sort of took the second route, because of the cocoa difference.
solution might be easy with some C knowledge, at least with adding a simple second argument like here in gtk.c, doing the same in windows.c is just a matter of giving the right kind of "string" to the function, in cocoa maybe just creating an appropriate variable and giving it "toalertWithMessageText:" (??)
if involving an optional hash variable to shoes_dialog_alert ... i need ... some more digging :-D

i think i need to work with stuff like

shoes_dialog_alert2(int argc, VALUE *argv, VALUE self)
rb_arg_list args;
rb_parse_args(argc, argv, "s|h", &args); what would be the right param here instead of "s|h"

might not have enough time in very near future to get a good basic understanding of this :-(

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 13, 2015

Contributor

The good news is Shoes 3.2 uses gtk for Windows so we only have to do this in gtk.c and cocoa.m. There are plenty of examples in gtk.c, app.c, canvas.c for dealing with optional hash arguments using the rb_api.

Contributor

ccoupe commented Feb 13, 2015

The good news is Shoes 3.2 uses gtk for Windows so we only have to do this in gtk.c and cocoa.m. There are plenty of examples in gtk.c, app.c, canvas.c for dealing with optional hash arguments using the rb_api.

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 13, 2015

Contributor

shoes_dialog_ask (in gtk.c) also need the same help as alert. It also shows how to parse a complex arg list. shoes_app_window() in app.c is an even better example. rb_parse_args is in ruby.c.

Contributor

ccoupe commented Feb 13, 2015

shoes_dialog_ask (in gtk.c) also need the same help as alert. It also shows how to parse a complex arg list. shoes_app_window() in app.c is an even better example. rb_parse_args is in ruby.c.

@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Feb 13, 2015

Collaborator

Simply :title would be better than :app_title. The ability to have no title at all would be good as well.

Why can't we say something like... if there is one parameter, it is a message, if there are two, it is a title and a message?

alert("this is an alert")
alert("Your consciousness", "this is an alert")
alert("this is an alert", :notitle => true)
Collaborator

BackOrder commented Feb 13, 2015

Simply :title would be better than :app_title. The ability to have no title at all would be good as well.

Why can't we say something like... if there is one parameter, it is a message, if there are two, it is a title and a message?

alert("this is an alert")
alert("Your consciousness", "this is an alert")
alert("this is an alert", :notitle => true)
@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 13, 2015

Contributor

@BackOrder, I like your proposal better than mine. Since the change affects lot of files, this is probably a good time to learn about git branches so that it doesn't get in the way of the 3.2.21 release.

Contributor

ccoupe commented Feb 13, 2015

@BackOrder, I like your proposal better than mine. Since the change affects lot of files, this is probably a good time to learn about git branches so that it doesn't get in the way of the 3.2.21 release.

@passenger94

This comment has been minimized.

Show comment
Hide comment
@passenger94

passenger94 Feb 13, 2015

Contributor
VALUE
shoes_dialog_alert3(int argc, VALUE *argv, VALUE self)
{
    rb_arg_list args;
    char *atitle = "";
    char *msg = "";
    rb_parse_args(argc, argv, "s|h", &args);
    msg = RSTRING_PTR(args.a[0]);
    if (RTEST(ATTR(args.a[1], title))) atitle = RSTRING_PTR(ATTR(args.a[1], title));

    GLOBAL_APP(app);
    GtkWidget *dialog = gtk_message_dialog_new_with_markup(
        APP_WINDOW(app), GTK_DIALOG_MODAL, GTK_MESSAGE_INFO, GTK_BUTTONS_OK, 
        "<span size='larger'>%s</span>\n\n%s", atitle, msg );

    gtk_dialog_run(GTK_DIALOG(dialog));
    gtk_widget_destroy(dialog);
    return Qnil;
}
# encoding: utf-8
Shoes.app(:title => "Shoes Custom Alert", :width => 450, :height => 250) {
    button("alert3") { alert3("alert message", title: "Custom title â é ! ") }
    button("alert3b") { alert3("alert message") }
}

works for me with in native.c and ruby.c

VALUE shoes_dialog_alert3(int argc, VALUE *argv, VALUE self);
rb_define_method(rb_mKernel, "alert3", CASTHOOK(shoes_dialog_alert3), -1);

Contributor

passenger94 commented Feb 13, 2015

VALUE
shoes_dialog_alert3(int argc, VALUE *argv, VALUE self)
{
    rb_arg_list args;
    char *atitle = "";
    char *msg = "";
    rb_parse_args(argc, argv, "s|h", &args);
    msg = RSTRING_PTR(args.a[0]);
    if (RTEST(ATTR(args.a[1], title))) atitle = RSTRING_PTR(ATTR(args.a[1], title));

    GLOBAL_APP(app);
    GtkWidget *dialog = gtk_message_dialog_new_with_markup(
        APP_WINDOW(app), GTK_DIALOG_MODAL, GTK_MESSAGE_INFO, GTK_BUTTONS_OK, 
        "<span size='larger'>%s</span>\n\n%s", atitle, msg );

    gtk_dialog_run(GTK_DIALOG(dialog));
    gtk_widget_destroy(dialog);
    return Qnil;
}
# encoding: utf-8
Shoes.app(:title => "Shoes Custom Alert", :width => 450, :height => 250) {
    button("alert3") { alert3("alert message", title: "Custom title â é ! ") }
    button("alert3b") { alert3("alert message") }
}

works for me with in native.c and ruby.c

VALUE shoes_dialog_alert3(int argc, VALUE *argv, VALUE self);
rb_define_method(rb_mKernel, "alert3", CASTHOOK(shoes_dialog_alert3), -1);

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 15, 2015

Contributor

Tobi (Shoes 4) suggests :
I'd propose to do it all with the options hash, like:

alert("some alert", title: "this is the title")
alert("some alert", title: :none) # could also be nil

And for app level styling I'd propose using the style method to change it everywhere:

style Shoes::Ask, title: "the new app wide title"

I like that too. I don't know if Shoes 3.2 has a Shoes.style method. I'd prefer title: nil over title: :none
Opinions?

Contributor

ccoupe commented Feb 15, 2015

Tobi (Shoes 4) suggests :
I'd propose to do it all with the options hash, like:

alert("some alert", title: "this is the title")
alert("some alert", title: :none) # could also be nil

And for app level styling I'd propose using the style method to change it everywhere:

style Shoes::Ask, title: "the new app wide title"

I like that too. I don't know if Shoes 3.2 has a Shoes.style method. I'd prefer title: nil over title: :none
Opinions?

@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Feb 15, 2015

Collaborator

I'd prefer title: nil over title: :none

nil or false would be preferred.

alert("some alert", title: "this is the title")
alert("some alert", title: false) 
alert("some alert", title: nil) 

I don't know if Shoes 3.2 has a Shoes.style method.

There is and it is used in Shoes 3.2 as shown below: https://github.com/Shoes3/shoes3/blob/master/lib/shoes/help.rb#L451

Collaborator

BackOrder commented Feb 15, 2015

I'd prefer title: nil over title: :none

nil or false would be preferred.

alert("some alert", title: "this is the title")
alert("some alert", title: false) 
alert("some alert", title: nil) 

I don't know if Shoes 3.2 has a Shoes.style method.

There is and it is used in Shoes 3.2 as shown below: https://github.com/Shoes3/shoes3/blob/master/lib/shoes/help.rb#L451

@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Feb 20, 2015

Collaborator

@passenger94, you did really well on the proof of concept. Would you be interested to complete it as a full replacement for Shoes alert? If so, it can be included in the upcoming 3.2.22 release.

Collaborator

BackOrder commented Feb 20, 2015

@passenger94, you did really well on the proof of concept. Would you be interested to complete it as a full replacement for Shoes alert? If so, it can be included in the upcoming 3.2.22 release.

@passenger94

This comment has been minimized.

Show comment
Hide comment
@passenger94

passenger94 Feb 21, 2015

Contributor

Yes sure, I will be able to concentrate on this next week :-)
I have no way to test cocoa code though

Contributor

passenger94 commented Feb 21, 2015

Yes sure, I will be able to concentrate on this next week :-)
I have no way to test cocoa code though

@BackOrder BackOrder added this to the 3.2.22 milestone Feb 21, 2015

@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Feb 21, 2015

Collaborator

Excellent. You do your best and @ccoupe and I can test Cocoa code. The code most likely need safeguards and support for title: nil.

Collaborator

BackOrder commented Feb 21, 2015

Excellent. You do your best and @ccoupe and I can test Cocoa code. The code most likely need safeguards and support for title: nil.

@passenger94

This comment has been minimized.

Show comment
Hide comment
@passenger94

passenger94 Feb 24, 2015

Contributor

so far this works for me,with appropriate changes in native.h and ruby.c
revisions more than welcome !

VALUE
shoes_dialog_alert3(int argc, VALUE *argv, VALUE self)
{
    rb_arg_list args;
    char *atitle = "";
    char *msg = "";
    rb_parse_args(argc, argv, "s|h", &args);
    msg = RSTRING_PTR(args.a[0]);   
    GLOBAL_APP(app);
    GtkWidget *dialog;
    char *format_string[50];

    if (RTEST(ATTR(args.a[1], title))) 
    {
        atitle = RSTRING_PTR(ATTR(args.a[1], title));
        snprintf(format_string, sizeof(format_string), "<span size='larger'>%s</span>\n\n%s", atitle, msg);
    }
    else
    {
        snprintf(format_string, sizeof(format_string), "%s", msg);
    }
    dialog = gtk_message_dialog_new_with_markup(
            APP_WINDOW(app), GTK_DIALOG_MODAL, GTK_MESSAGE_INFO, GTK_BUTTONS_OK, 
            format_string );

    gtk_dialog_run(GTK_DIALOG(dialog));
    gtk_widget_destroy(dialog);
    return Qnil;
}
VALUE
shoes_dialog_ask2(int argc, VALUE *argv, VALUE self)
{
  rb_arg_list args;
  char *atitle = "";
  VALUE answer = Qnil;
  rb_parse_args(argc, argv, "s|h", &args);

  if (RTEST(ATTR(args.a[1], title))) atitle = RSTRING_PTR(ATTR(args.a[1], title));

  GLOBAL_APP(app);
  GtkWidget *dialog = gtk_dialog_new_with_buttons(atitle,
    APP_WINDOW(app), GTK_DIALOG_MODAL, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, GTK_STOCK_OK, GTK_RESPONSE_OK, NULL);
  gtk_container_set_border_width(GTK_CONTAINER(dialog), 6);
#ifdef GTK3
  gtk_container_set_border_width(GTK_CONTAINER(gtk_dialog_get_content_area(GTK_DIALOG(dialog))), 6);
#else
  gtk_container_set_border_width(GTK_CONTAINER(GTK_DIALOG(dialog)->vbox), 6);
#endif
  GtkWidget *question = gtk_label_new(RSTRING_PTR(args.a[0]));
  gtk_misc_set_alignment(GTK_MISC(question), 0, 0);
  GtkWidget *_answer = gtk_entry_new();
  if (RTEST(ATTR(args.a[1], secret))) shoes_native_secrecy(_answer);
#ifdef GTK3
  gtk_box_pack_start(GTK_BOX(gtk_dialog_get_content_area(GTK_DIALOG(dialog))), question, FALSE, FALSE, 3);
  gtk_box_pack_start(GTK_BOX(gtk_dialog_get_content_area(GTK_DIALOG(dialog))), _answer, FALSE, TRUE, 3);
#else
  gtk_box_pack_start(GTK_BOX(GTK_DIALOG(dialog)->vbox), question, FALSE, FALSE, 3);
  gtk_box_pack_start(GTK_BOX(GTK_DIALOG(dialog)->vbox), _answer, FALSE, TRUE, 3);
#endif
  gtk_widget_show_all(dialog);
  gint result = gtk_dialog_run(GTK_DIALOG(dialog));
  if (result == GTK_RESPONSE_OK)
  {
    const gchar *txt = gtk_entry_get_text(GTK_ENTRY(_answer));
    answer = rb_str_new2(txt);
  }
  gtk_widget_destroy(dialog);
  return answer;
}

test app :

Shoes.app(:title => "Shoes Custom Ask & Alert", :width => 450, :height => 250) {
    name = ask2("Please, enter your name:", title: "May i ?")
    alert3 "your name is #{name}", title: "Excellent !"
    name = ask2("Please, enter your name:", title: nil)
    alert3 "your name is #{name}", title: nil
}

For the global style
do we need to create Shoes::Alert and Shoes::Ask Classes in order to set styles on them ?
something like cAlert = rb_define_class_under(cTypes, "Alert", rb_cObject);

Contributor

passenger94 commented Feb 24, 2015

so far this works for me,with appropriate changes in native.h and ruby.c
revisions more than welcome !

VALUE
shoes_dialog_alert3(int argc, VALUE *argv, VALUE self)
{
    rb_arg_list args;
    char *atitle = "";
    char *msg = "";
    rb_parse_args(argc, argv, "s|h", &args);
    msg = RSTRING_PTR(args.a[0]);   
    GLOBAL_APP(app);
    GtkWidget *dialog;
    char *format_string[50];

    if (RTEST(ATTR(args.a[1], title))) 
    {
        atitle = RSTRING_PTR(ATTR(args.a[1], title));
        snprintf(format_string, sizeof(format_string), "<span size='larger'>%s</span>\n\n%s", atitle, msg);
    }
    else
    {
        snprintf(format_string, sizeof(format_string), "%s", msg);
    }
    dialog = gtk_message_dialog_new_with_markup(
            APP_WINDOW(app), GTK_DIALOG_MODAL, GTK_MESSAGE_INFO, GTK_BUTTONS_OK, 
            format_string );

    gtk_dialog_run(GTK_DIALOG(dialog));
    gtk_widget_destroy(dialog);
    return Qnil;
}
VALUE
shoes_dialog_ask2(int argc, VALUE *argv, VALUE self)
{
  rb_arg_list args;
  char *atitle = "";
  VALUE answer = Qnil;
  rb_parse_args(argc, argv, "s|h", &args);

  if (RTEST(ATTR(args.a[1], title))) atitle = RSTRING_PTR(ATTR(args.a[1], title));

  GLOBAL_APP(app);
  GtkWidget *dialog = gtk_dialog_new_with_buttons(atitle,
    APP_WINDOW(app), GTK_DIALOG_MODAL, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, GTK_STOCK_OK, GTK_RESPONSE_OK, NULL);
  gtk_container_set_border_width(GTK_CONTAINER(dialog), 6);
#ifdef GTK3
  gtk_container_set_border_width(GTK_CONTAINER(gtk_dialog_get_content_area(GTK_DIALOG(dialog))), 6);
#else
  gtk_container_set_border_width(GTK_CONTAINER(GTK_DIALOG(dialog)->vbox), 6);
#endif
  GtkWidget *question = gtk_label_new(RSTRING_PTR(args.a[0]));
  gtk_misc_set_alignment(GTK_MISC(question), 0, 0);
  GtkWidget *_answer = gtk_entry_new();
  if (RTEST(ATTR(args.a[1], secret))) shoes_native_secrecy(_answer);
#ifdef GTK3
  gtk_box_pack_start(GTK_BOX(gtk_dialog_get_content_area(GTK_DIALOG(dialog))), question, FALSE, FALSE, 3);
  gtk_box_pack_start(GTK_BOX(gtk_dialog_get_content_area(GTK_DIALOG(dialog))), _answer, FALSE, TRUE, 3);
#else
  gtk_box_pack_start(GTK_BOX(GTK_DIALOG(dialog)->vbox), question, FALSE, FALSE, 3);
  gtk_box_pack_start(GTK_BOX(GTK_DIALOG(dialog)->vbox), _answer, FALSE, TRUE, 3);
#endif
  gtk_widget_show_all(dialog);
  gint result = gtk_dialog_run(GTK_DIALOG(dialog));
  if (result == GTK_RESPONSE_OK)
  {
    const gchar *txt = gtk_entry_get_text(GTK_ENTRY(_answer));
    answer = rb_str_new2(txt);
  }
  gtk_widget_destroy(dialog);
  return answer;
}

test app :

Shoes.app(:title => "Shoes Custom Ask & Alert", :width => 450, :height => 250) {
    name = ask2("Please, enter your name:", title: "May i ?")
    alert3 "your name is #{name}", title: "Excellent !"
    name = ask2("Please, enter your name:", title: nil)
    alert3 "your name is #{name}", title: nil
}

For the global style
do we need to create Shoes::Alert and Shoes::Ask Classes in order to set styles on them ?
something like cAlert = rb_define_class_under(cTypes, "Alert", rb_cObject);

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 25, 2015

Contributor

@passenger94 - I haven't tried your code yet - I will later today, if Ian doesn't do it first.

I don't have a strong feeling one way or the other about the global styles. Thats more of a Shoes4 idea. For now, I'd default to using the global dialog_title strings. It's easy enough for someone to specify a different title on the ask and alert if they want with the changes you've made.

I'm not opposed to the new classes, either although I suspect it's a larger change than we think.

Contributor

ccoupe commented Feb 25, 2015

@passenger94 - I haven't tried your code yet - I will later today, if Ian doesn't do it first.

I don't have a strong feeling one way or the other about the global styles. Thats more of a Shoes4 idea. For now, I'd default to using the global dialog_title strings. It's easy enough for someone to specify a different title on the ask and alert if they want with the changes you've made.

I'm not opposed to the new classes, either although I suspect it's a larger change than we think.

@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Feb 25, 2015

Collaborator

I'd say CLASS_COMMON(alert) will do the trick. The macro will create a new function shoes_alert_style() that provides self->attr containing a hash with the style.

https://github.com/Shoes3/shoes3/blob/master/shoes/ruby.c#L3779 (the code should be appended here)
https://github.com/Shoes3/shoes3/blob/master/shoes/ruby.c#L3643 (CLASS_COMMON definition)

Collaborator

BackOrder commented Feb 25, 2015

I'd say CLASS_COMMON(alert) will do the trick. The macro will create a new function shoes_alert_style() that provides self->attr containing a hash with the style.

https://github.com/Shoes3/shoes3/blob/master/shoes/ruby.c#L3779 (the code should be appended here)
https://github.com/Shoes3/shoes3/blob/master/shoes/ruby.c#L3643 (CLASS_COMMON definition)

@passenger94

This comment has been minimized.

Show comment
Hide comment
@passenger94

passenger94 Feb 25, 2015

Contributor

@ccoupe yes not clear to me yet what to do exactly to create the feature

oh if you want to test here some copy/paste facilities
in native.h

VALUE shoes_dialog_alert3(int argc, VALUE *argv, VALUE self);
VALUE shoes_dialog_ask2(int argc, VALUE *argv, VALUE self);

in ruby.c

  rb_define_method(rb_mKernel, "alert3", CASTHOOK(shoes_dialog_alert3), -1);
  rb_define_method(rb_mKernel, "ask2", CASTHOOK(shoes_dialog_ask2), -1);

@BackOrder will try, thanks

Contributor

passenger94 commented Feb 25, 2015

@ccoupe yes not clear to me yet what to do exactly to create the feature

oh if you want to test here some copy/paste facilities
in native.h

VALUE shoes_dialog_alert3(int argc, VALUE *argv, VALUE self);
VALUE shoes_dialog_ask2(int argc, VALUE *argv, VALUE self);

in ruby.c

  rb_define_method(rb_mKernel, "alert3", CASTHOOK(shoes_dialog_alert3), -1);
  rb_define_method(rb_mKernel, "ask2", CASTHOOK(shoes_dialog_ask2), -1);

@BackOrder will try, thanks

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 25, 2015

Contributor

@passenger94 - we want to handle the old style ask and alert - a more complete test program is

Shoes.app(:title => "Shoes Custom Ask & Alert", :width => 450, :height => 250) {
    #test default title - the hardcoded strings "Shoes says", "Shoes asks"
    name = ask("Please enter your name:")
    alert "your name is #{name}"
    # test user supplied title
    name = ask("Please, enter your name:", title: "May i ?")
    alert "your name is #{name}", title: "Excellent !"
    # test no title at all
    name = ask("Please, enter your name:", title: nil)
    alert "your name is #{name}", title: nil
}

I did try your code in a git branch 'newask' that is local to me so I just replaced the existing code instead of creating new names and I started to modify your code to handle the default case and realized I'd step all over you when it came time to commit.

Contributor

ccoupe commented Feb 25, 2015

@passenger94 - we want to handle the old style ask and alert - a more complete test program is

Shoes.app(:title => "Shoes Custom Ask & Alert", :width => 450, :height => 250) {
    #test default title - the hardcoded strings "Shoes says", "Shoes asks"
    name = ask("Please enter your name:")
    alert "your name is #{name}"
    # test user supplied title
    name = ask("Please, enter your name:", title: "May i ?")
    alert "your name is #{name}", title: "Excellent !"
    # test no title at all
    name = ask("Please, enter your name:", title: nil)
    alert "your name is #{name}", title: nil
}

I did try your code in a git branch 'newask' that is local to me so I just replaced the existing code instead of creating new names and I started to modify your code to handle the default case and realized I'd step all over you when it came time to commit.

@passenger94

This comment has been minimized.

Show comment
Hide comment
@passenger94

passenger94 Feb 25, 2015

Contributor

@ccoupe no problem go ahead, please ! :-)

i came up with this

VALUE
shoes_dialog_alert(int argc, VALUE *argv, VALUE self)
{
    rb_arg_list args;
    char *atitle = "Shoes says:";
    char *msg = "";
    rb_parse_args(argc, argv, "s|h", &args);
    msg = RSTRING_PTR(args.a[0]);   
    GLOBAL_APP(app);
    GtkWidget *dialog;
    char *format_string[50];
    switch(argc)
    {
    case 1:
        snprintf(format_string, sizeof(format_string), "<span size='larger'>%s</span>\n\n%s", atitle, msg);
        break;
    case 2:
        if (RTEST(ATTR(args.a[1], title)))
        {
            atitle = RSTRING_PTR(ATTR(args.a[1], title));
            snprintf(format_string, sizeof(format_string), "<span size='larger'>%s</span>\n\n%s", atitle, msg);
        }
        else
        {
            snprintf(format_string, sizeof(format_string), "%s", msg);
        }
        break;
    }

    dialog = gtk_message_dialog_new_with_markup(
            APP_WINDOW(app), GTK_DIALOG_MODAL, GTK_MESSAGE_INFO, GTK_BUTTONS_OK, 
            format_string );

    gtk_dialog_run(GTK_DIALOG(dialog));
    gtk_widget_destroy(dialog);
    return Qnil;
}
VALUE
shoes_dialog_ask(int argc, VALUE *argv, VALUE self)
{
  rb_arg_list args;
  char *atitle = "";
  VALUE answer = Qnil;
  rb_parse_args(argc, argv, "s|h", &args);

    switch(argc)
    {
    case 1:
        atitle = "Shoes asks:";
        break;
    case 2:
        if (RTEST(ATTR(args.a[1], title))) atitle = RSTRING_PTR(ATTR(args.a[1], title));
        break;
    }

  GLOBAL_APP(app);
  GtkWidget *dialog = gtk_dialog_new_with_buttons(atitle,
    APP_WINDOW(app), GTK_DIALOG_MODAL, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, GTK_STOCK_OK, GTK_RESPONSE_OK, NULL);
  gtk_container_set_border_width(GTK_CONTAINER(dialog), 6);
#ifdef GTK3
  gtk_container_set_border_width(GTK_CONTAINER(gtk_dialog_get_content_area(GTK_DIALOG(dialog))), 6);
#else
  gtk_container_set_border_width(GTK_CONTAINER(GTK_DIALOG(dialog)->vbox), 6);
#endif
  GtkWidget *question = gtk_label_new(RSTRING_PTR(args.a[0]));
  gtk_misc_set_alignment(GTK_MISC(question), 0, 0);
  GtkWidget *_answer = gtk_entry_new();
  if (RTEST(ATTR(args.a[1], secret))) shoes_native_secrecy(_answer);
#ifdef GTK3
  gtk_box_pack_start(GTK_BOX(gtk_dialog_get_content_area(GTK_DIALOG(dialog))), question, FALSE, FALSE, 3);
  gtk_box_pack_start(GTK_BOX(gtk_dialog_get_content_area(GTK_DIALOG(dialog))), _answer, FALSE, TRUE, 3);
#else
  gtk_box_pack_start(GTK_BOX(GTK_DIALOG(dialog)->vbox), question, FALSE, FALSE, 3);
  gtk_box_pack_start(GTK_BOX(GTK_DIALOG(dialog)->vbox), _answer, FALSE, TRUE, 3);
#endif
  gtk_widget_show_all(dialog);
  gint result = gtk_dialog_run(GTK_DIALOG(dialog));
  if (result == GTK_RESPONSE_OK)
  {
    const gchar *txt = gtk_entry_get_text(GTK_ENTRY(_answer));
    answer = rb_str_new2(txt);
  }
  gtk_widget_destroy(dialog);
  return answer;
}

works with your test app
one can also declare default *char atitle = "Shoes asks:"; but it means a suplementary else branch, probably cleaner ?

for the commit it's probably safe to get rid of

const char *dialog_title = USTR("Shoes asks:");
const char *dialog_title_says = USTR("Shoes says:");

in canvas.c
Those are used only once and defined far from the place they are used ...

Contributor

passenger94 commented Feb 25, 2015

@ccoupe no problem go ahead, please ! :-)

i came up with this

VALUE
shoes_dialog_alert(int argc, VALUE *argv, VALUE self)
{
    rb_arg_list args;
    char *atitle = "Shoes says:";
    char *msg = "";
    rb_parse_args(argc, argv, "s|h", &args);
    msg = RSTRING_PTR(args.a[0]);   
    GLOBAL_APP(app);
    GtkWidget *dialog;
    char *format_string[50];
    switch(argc)
    {
    case 1:
        snprintf(format_string, sizeof(format_string), "<span size='larger'>%s</span>\n\n%s", atitle, msg);
        break;
    case 2:
        if (RTEST(ATTR(args.a[1], title)))
        {
            atitle = RSTRING_PTR(ATTR(args.a[1], title));
            snprintf(format_string, sizeof(format_string), "<span size='larger'>%s</span>\n\n%s", atitle, msg);
        }
        else
        {
            snprintf(format_string, sizeof(format_string), "%s", msg);
        }
        break;
    }

    dialog = gtk_message_dialog_new_with_markup(
            APP_WINDOW(app), GTK_DIALOG_MODAL, GTK_MESSAGE_INFO, GTK_BUTTONS_OK, 
            format_string );

    gtk_dialog_run(GTK_DIALOG(dialog));
    gtk_widget_destroy(dialog);
    return Qnil;
}
VALUE
shoes_dialog_ask(int argc, VALUE *argv, VALUE self)
{
  rb_arg_list args;
  char *atitle = "";
  VALUE answer = Qnil;
  rb_parse_args(argc, argv, "s|h", &args);

    switch(argc)
    {
    case 1:
        atitle = "Shoes asks:";
        break;
    case 2:
        if (RTEST(ATTR(args.a[1], title))) atitle = RSTRING_PTR(ATTR(args.a[1], title));
        break;
    }

  GLOBAL_APP(app);
  GtkWidget *dialog = gtk_dialog_new_with_buttons(atitle,
    APP_WINDOW(app), GTK_DIALOG_MODAL, GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, GTK_STOCK_OK, GTK_RESPONSE_OK, NULL);
  gtk_container_set_border_width(GTK_CONTAINER(dialog), 6);
#ifdef GTK3
  gtk_container_set_border_width(GTK_CONTAINER(gtk_dialog_get_content_area(GTK_DIALOG(dialog))), 6);
#else
  gtk_container_set_border_width(GTK_CONTAINER(GTK_DIALOG(dialog)->vbox), 6);
#endif
  GtkWidget *question = gtk_label_new(RSTRING_PTR(args.a[0]));
  gtk_misc_set_alignment(GTK_MISC(question), 0, 0);
  GtkWidget *_answer = gtk_entry_new();
  if (RTEST(ATTR(args.a[1], secret))) shoes_native_secrecy(_answer);
#ifdef GTK3
  gtk_box_pack_start(GTK_BOX(gtk_dialog_get_content_area(GTK_DIALOG(dialog))), question, FALSE, FALSE, 3);
  gtk_box_pack_start(GTK_BOX(gtk_dialog_get_content_area(GTK_DIALOG(dialog))), _answer, FALSE, TRUE, 3);
#else
  gtk_box_pack_start(GTK_BOX(GTK_DIALOG(dialog)->vbox), question, FALSE, FALSE, 3);
  gtk_box_pack_start(GTK_BOX(GTK_DIALOG(dialog)->vbox), _answer, FALSE, TRUE, 3);
#endif
  gtk_widget_show_all(dialog);
  gint result = gtk_dialog_run(GTK_DIALOG(dialog));
  if (result == GTK_RESPONSE_OK)
  {
    const gchar *txt = gtk_entry_get_text(GTK_ENTRY(_answer));
    answer = rb_str_new2(txt);
  }
  gtk_widget_destroy(dialog);
  return answer;
}

works with your test app
one can also declare default *char atitle = "Shoes asks:"; but it means a suplementary else branch, probably cleaner ?

for the commit it's probably safe to get rid of

const char *dialog_title = USTR("Shoes asks:");
const char *dialog_title_says = USTR("Shoes says:");

in canvas.c
Those are used only once and defined far from the place they are used ...

@passenger94

This comment has been minimized.

Show comment
Hide comment
@passenger94

passenger94 Feb 25, 2015

Contributor

@BackOrder
from what i understand CLASS_COMMON(alert) to work needs alert to be a Structure, one have to define an Alert class and a shoe_alert_alloc function, i believe (or making Alert Class a child of cShoesWindow/cDialog ?)
also CLASS_COMMON will create a shoes_alert_displace and shoes_alert_move, not sure those will do good ! -> rewrite another specific CLASS_COMMON ?

Contributor

passenger94 commented Feb 25, 2015

@BackOrder
from what i understand CLASS_COMMON(alert) to work needs alert to be a Structure, one have to define an Alert class and a shoe_alert_alloc function, i believe (or making Alert Class a child of cShoesWindow/cDialog ?)
also CLASS_COMMON will create a shoes_alert_displace and shoes_alert_move, not sure those will do good ! -> rewrite another specific CLASS_COMMON ?

@passenger94

This comment has been minimized.

Show comment
Hide comment
@passenger94

passenger94 Feb 25, 2015

Contributor

ok i made a newask branch, doing a pull request so you can review code there

btw there is also confirm dialog which uses "shoes asks" / dialog_title
same treatment ?
done in newask branch

Contributor

passenger94 commented Feb 25, 2015

ok i made a newask branch, doing a pull request so you can review code there

btw there is also confirm dialog which uses "shoes asks" / dialog_title
same treatment ?
done in newask branch

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 25, 2015

Contributor

The new code works fine on my Linux box. Thanks. The next question is "Do we want to implement the Styles code?" If we do, then we should do that before working the cocoa.m.

Contributor

ccoupe commented Feb 25, 2015

The new code works fine on my Linux box. Thanks. The next question is "Do we want to implement the Styles code?" If we do, then we should do that before working the cocoa.m.

@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Feb 25, 2015

Collaborator

The next question is "Do we want to implement the Styles code?"

A good argument in favour is that it could be part of a Developer's Guide to Shoes where we can write on how to add features to Shoes such as alert, style, SVG, etc. As you know, I am always documenting on my end.

Collaborator

BackOrder commented Feb 25, 2015

The next question is "Do we want to implement the Styles code?"

A good argument in favour is that it could be part of a Developer's Guide to Shoes where we can write on how to add features to Shoes such as alert, style, SVG, etc. As you know, I am always documenting on my end.

@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Feb 25, 2015

Collaborator

Synced with github, gave a try to the code and found two bugs. Recommendation: the code should attempt to convert whatever is input for title to a string and raise an exception when the conversion fail.

Crashing Shoes with a number

Shoes.app(:title => "Shoes Custom Ask & Alert", :width => 450, :height => 250) {
    alert "This is an alerting alert.", title: 12345
}

Crashing Shoes with a hash

Shoes.app(:title => "Shoes Custom Ask & Alert", :width => 450, :height => 250) {
    alert "This is an alerting alert.", title: { :a => "hey" }
}

Shoes is reporting a Gtk-WARNING when a hash is used

(cshoes.exe:5904): Gtk-WARNING **: Failed to set text from markup due to error p
arsing markup: Error on line 1 char 33: Invalid UTF-8 encoded text in name - not
 valid '`@\x8a\u0002'
Collaborator

BackOrder commented Feb 25, 2015

Synced with github, gave a try to the code and found two bugs. Recommendation: the code should attempt to convert whatever is input for title to a string and raise an exception when the conversion fail.

Crashing Shoes with a number

Shoes.app(:title => "Shoes Custom Ask & Alert", :width => 450, :height => 250) {
    alert "This is an alerting alert.", title: 12345
}

Crashing Shoes with a hash

Shoes.app(:title => "Shoes Custom Ask & Alert", :width => 450, :height => 250) {
    alert "This is an alerting alert.", title: { :a => "hey" }
}

Shoes is reporting a Gtk-WARNING when a hash is used

(cshoes.exe:5904): Gtk-WARNING **: Failed to set text from markup due to error p
arsing markup: Error on line 1 char 33: Invalid UTF-8 encoded text in name - not
 valid '`@\x8a\u0002'

ccoupe added a commit that referenced this issue Feb 26, 2015

cocoa.m shoes_dialog_alert for #59. W/o coercion.
* Beware - I get two Shoes.app's. Not sure where that came from.

ccoupe added a commit that referenced this issue Feb 27, 2015

ask, alert, confirm allow optional :title => nil or "string" #59
* NOTE: test program bug059.rb on OSX has two Shoes.app !!
* coerces :title arg to string
* does NOT implement styles class for default.
@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 27, 2015

Contributor

I've committed changes for OSX and GTK for alert,ask,confirm to handle the optional :title arg . They attempt to convert user mistakes with :title into strings. h/t @passenger94.

There is a weird bug in OSX. There are two Shoes.app's created by one call in bug059.rb. Hard to believe this fix created that problem.

Now we a volunteer to implement the styles handling in ruby.c and modify gtk.c and cocoa.m Anyone?

Contributor

ccoupe commented Feb 27, 2015

I've committed changes for OSX and GTK for alert,ask,confirm to handle the optional :title arg . They attempt to convert user mistakes with :title into strings. h/t @passenger94.

There is a weird bug in OSX. There are two Shoes.app's created by one call in bug059.rb. Hard to believe this fix created that problem.

Now we a volunteer to implement the styles handling in ruby.c and modify gtk.c and cocoa.m Anyone?

@passenger94

This comment has been minimized.

Show comment
Hide comment
@passenger94

passenger94 Feb 27, 2015

Contributor

proposal for manual :

=== alert(message: a string, :title => a string or nil) » nil ===

Pops up a window containing a short message.

{{{
 #!ruby
 alert("I'm afraid I must interject!")
}}}

`:title` is optional and replace the default "Shoes says:" with the string you provide or could be set to `nil` in wich case the window won't have a title at all.

{{{
 #!ruby
 alert("I'm afraid I must interject!", :title => "Sorry but :")
}}}

{{{
 #!ruby
 alert("I'm afraid I must interject!", :title => nil)
}}}

Please use alerts sparingly, as they are incredibly annoying!  If you are using
alerts to show messages to help you debug your program, try checking out the
[[Built-in.debug]] or [[Built-in.info]] methods.

=== ask(message: a string, :title => a string or nil) » a string ===

Pops up a window and asks a question. For example, you may want to ask someone
their name.

{{{
 #!ruby
 name = ask("Please, enter your name:")
}}}

When the above script is run, the person at the computer will see a window with
a blank box for entering their name. The name will then be saved in the `name`
variable.

`:title` is optional and replace the default "Shoes asks:" with the string you provide or could be set to `nil` in wich case the window won't have a title at all.
See [[Built-in.alert]] method for similar examples.

........

=== confirm(question: a string, :title => a string or nil) » true or false ===

Pops up a yes-or-no question. If the person at the computer, clicks '''yes''',
you'll get back a `true`. If not, you'll get back `false`.

{{{
 #!ruby
 if confirm("Draw a circle?")
  Shoes.app{ oval :top => 0, :left => 0, :radius => 50 }
 end
}}}

`:title` is optional and replace the default "Shoes asks:" with the string you provide or could be set to `nil` in wich case the window won't have a title at all.
See [[Built-in.alert]] method for similar examples.

alertask

Contributor

passenger94 commented Feb 27, 2015

proposal for manual :

=== alert(message: a string, :title => a string or nil) » nil ===

Pops up a window containing a short message.

{{{
 #!ruby
 alert("I'm afraid I must interject!")
}}}

`:title` is optional and replace the default "Shoes says:" with the string you provide or could be set to `nil` in wich case the window won't have a title at all.

{{{
 #!ruby
 alert("I'm afraid I must interject!", :title => "Sorry but :")
}}}

{{{
 #!ruby
 alert("I'm afraid I must interject!", :title => nil)
}}}

Please use alerts sparingly, as they are incredibly annoying!  If you are using
alerts to show messages to help you debug your program, try checking out the
[[Built-in.debug]] or [[Built-in.info]] methods.

=== ask(message: a string, :title => a string or nil) » a string ===

Pops up a window and asks a question. For example, you may want to ask someone
their name.

{{{
 #!ruby
 name = ask("Please, enter your name:")
}}}

When the above script is run, the person at the computer will see a window with
a blank box for entering their name. The name will then be saved in the `name`
variable.

`:title` is optional and replace the default "Shoes asks:" with the string you provide or could be set to `nil` in wich case the window won't have a title at all.
See [[Built-in.alert]] method for similar examples.

........

=== confirm(question: a string, :title => a string or nil) » true or false ===

Pops up a yes-or-no question. If the person at the computer, clicks '''yes''',
you'll get back a `true`. If not, you'll get back `false`.

{{{
 #!ruby
 if confirm("Draw a circle?")
  Shoes.app{ oval :top => 0, :left => 0, :radius => 50 }
 end
}}}

`:title` is optional and replace the default "Shoes asks:" with the string you provide or could be set to `nil` in wich case the window won't have a title at all.
See [[Built-in.alert]] method for similar examples.

alertask

@passenger94

This comment has been minimized.

Show comment
Hide comment
@passenger94

passenger94 Feb 27, 2015

Contributor

@ccoupe, @BackOrder
from what i understand global style happens here :
https://github.com/Shoes3/shoes3/blob/master/shoes/app.c#L536
we need to create classes (cAlert, cAsk, cConfirm) subclasses of cApp, cShoes, cNative ...? or new ones with shoes_##_alloc ? in ruby.c with rb_define_class_under()
attach or delegate the alert/ask/confirm methods to those classes
then create a global style with the macro STYLE and add appropriate default in shoes_app_reset_styles

edit : i think we only need to add appropriate default in shoes_app_reset_styles once classes created

am i on good tracks ?

Contributor

passenger94 commented Feb 27, 2015

@ccoupe, @BackOrder
from what i understand global style happens here :
https://github.com/Shoes3/shoes3/blob/master/shoes/app.c#L536
we need to create classes (cAlert, cAsk, cConfirm) subclasses of cApp, cShoes, cNative ...? or new ones with shoes_##_alloc ? in ruby.c with rb_define_class_under()
attach or delegate the alert/ask/confirm methods to those classes
then create a global style with the macro STYLE and add appropriate default in shoes_app_reset_styles

edit : i think we only need to add appropriate default in shoes_app_reset_styles once classes created

am i on good tracks ?

@passenger94 passenger94 reopened this Feb 27, 2015

@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Feb 27, 2015

Collaborator

could be set to nil in which case the window won't have a title at all.

Spell checking, please!

Collaborator

BackOrder commented Feb 27, 2015

could be set to nil in which case the window won't have a title at all.

Spell checking, please!

@BackOrder

This comment has been minimized.

Show comment
Hide comment
@BackOrder

BackOrder Feb 27, 2015

Collaborator

You are really doing a great contribution, @passenger94. I am pleased that you have taken on from the implementation to the writing of the manual. The time you have taken to do this is time @ccoupe and I can spend on different parts of Shoes, thus improving Shoes at a greater speed. Thank you for your contribution. Keep it up!

Collaborator

BackOrder commented Feb 27, 2015

You are really doing a great contribution, @passenger94. I am pleased that you have taken on from the implementation to the writing of the manual. The time you have taken to do this is time @ccoupe and I can spend on different parts of Shoes, thus improving Shoes at a greater speed. Thank you for your contribution. Keep it up!

@passenger94

This comment has been minimized.

Show comment
Hide comment
@passenger94

passenger94 Feb 27, 2015

Contributor

@BackOrder Thanks for kind words !!! :-)
oops ! i really need to go through a spell checking in my editor to at least get rid of most obvious errors !!
very interesting journey so far, thanks for the ride :-D

Contributor

passenger94 commented Feb 27, 2015

@BackOrder Thanks for kind words !!! :-)
oops ! i really need to go through a spell checking in my editor to at least get rid of most obvious errors !!
very interesting journey so far, thanks for the ride :-D

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Feb 28, 2015

Contributor

It's been a big help to me because I know less that either of you two so it takes me longer to find solutions.

Contributor

ccoupe commented Feb 28, 2015

It's been a big help to me because I know less that either of you two so it takes me longer to find solutions.

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Mar 14, 2015

Contributor

Revisiting @passenger94's question. As currently written ask,alert,confirm are methods of rb_kernel as are quit, exit, system and rgb. The code for them is not really tied into the Shoes class structures -just into Ruby . We have a cDialog class but it appears to be unused (and no C structures for it - no dialog.h, dialog.c). @BackOrder also would like dialogs to have additional Shoes based functionality see #29

I happen to think these functions should be subclasses of a new Dialog class but I'm simple-minded. The C/Gtk/Cocoa code changes could be daunting but also implemented incrementally since they end up calling the existing exiting gtk/cocoa code, perhaps with a new VALUE app argument so they can find the strings and setting in new C level Dialog struct.

I'd also prefer to do something that wouldn't be that difficult for the Shoes4 folks to implement if they choose to - I suspect we might be catching up to their class layout which could be confusing since they want to emulate shoes 3.

If you agree with my assessment, would it make sense to close this issue and do the new Dialog design on #29 or start a new issue?

Contributor

ccoupe commented Mar 14, 2015

Revisiting @passenger94's question. As currently written ask,alert,confirm are methods of rb_kernel as are quit, exit, system and rgb. The code for them is not really tied into the Shoes class structures -just into Ruby . We have a cDialog class but it appears to be unused (and no C structures for it - no dialog.h, dialog.c). @BackOrder also would like dialogs to have additional Shoes based functionality see #29

I happen to think these functions should be subclasses of a new Dialog class but I'm simple-minded. The C/Gtk/Cocoa code changes could be daunting but also implemented incrementally since they end up calling the existing exiting gtk/cocoa code, perhaps with a new VALUE app argument so they can find the strings and setting in new C level Dialog struct.

I'd also prefer to do something that wouldn't be that difficult for the Shoes4 folks to implement if they choose to - I suspect we might be catching up to their class layout which could be confusing since they want to emulate shoes 3.

If you agree with my assessment, would it make sense to close this issue and do the new Dialog design on #29 or start a new issue?

@ccoupe

This comment has been minimized.

Show comment
Hide comment
@ccoupe

ccoupe Mar 24, 2015

Contributor

3.2.19 added a title field to the shoes_app structure (app.h) and an api to set it (and code in gtk and cocoa to read it). I even asked the Shoe4 folks if it was something they could live with. There is a packaging reason I didn't want to do it in styles. Anyway, it's there and we can use it. Just append 'says:' or 'asks:' to that value. The resulting gtk.c for alert,ask,confirm,code is very ugly. It needs to use the rb_ api or the gtk api to move the strings around.

Contributor

ccoupe commented Mar 24, 2015

3.2.19 added a title field to the shoes_app structure (app.h) and an api to set it (and code in gtk and cocoa to read it). I even asked the Shoe4 folks if it was something they could live with. There is a packaging reason I didn't want to do it in styles. Anyway, it's there and we can use it. Just append 'says:' or 'asks:' to that value. The resulting gtk.c for alert,ask,confirm,code is very ugly. It needs to use the rb_ api or the gtk api to move the strings around.

ccoupe added a commit that referenced this issue Mar 24, 2015

For #59 - we already have a user set title. (from 3.2.19) use it.
* Styles would be better but the secondary package installer needs to set it after the window/dialog is defined.
* the gtk.c code is really ugly. Even I am offended.
* osx/cocoa needs to handle that app->title

@ccoupe ccoupe closed this Mar 27, 2015

ccoupe added a commit that referenced this issue Mar 30, 2015

reduce gtk.c compile warning messages - more #93 and #59 stuff.
* xml entities like '&' are allowed. see bugs/bug059-1.rb
* for alerts, ask, confim a :title in the calling Shoes.app overrides the
  "Shoes says" - see bugs/bug059-1.rb
* app.set_window_title over rides both. see bugs/bug059-2.rb
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment