Allow setting font for native controls (widgets)

[ccoupe]

It's possible to set the font for any NSControl or Gtk3 widget but they do it differently. Gtk wants a pango font description (or it creates one from a string). OSX wants a fontObject (created from NSFont)

Shoes already has rich set of style names for textblock and a list of all the fonts available. We just need some native code similar shoes_app_style_for () to map the styles to to gtk_widgets or NSFont objects instead of cairo drawing attributes. And update all controls to do it.

[ccoupe]

I created a widgetfont branch. I start with button Here the test script (bugs/bug179.rb)

Shoes.app width: 300, height: 200 do
  stack do
    button "Button", font: "mono bold 14",fill: yellow, stroke: red do
    end
    button "Normal" do
    end
  end
end

Yes, the background is not yellow and and the stoke is not red -- but the font did change. And its only for linux/windows ... Work in progress.

[ccoupe]

The background color , #353 appears to be a incompatible idea. It's deprecated in Gtk 3.16 and works oddly below that when it deprecates an even older call. Also, it's not directly supported by Cocoa. However, both toolkits support icon images in a button along with some positioning options for image vs text - that seems doable.

There are issues with all those pango attributes& list that need dereferencing so it's still incomplete.

[ccoupe]

Here's the tooltip for an icon button.

Script:

Shoes.app width: 300, height: 200 do
  stack do
    flow do
      button "Button", font: "mono bold 14",width: 200, stroke: red,
          tooltip: "Red mono" do
      end
      button "icon", width: 30, height: 30, icon: "#{DIR}/static/icon-info.png",
          tooltip: "info button" do
      end
    end
    button "Normal", tooltip: "Normal" do
    end
  end
end

No, it's not correct IMO, but I like the direction. It's not like people haven't asked for this.

[IanTrudel]

It's looking good and promising.

[ccoupe]

Switching to OSX.

While it might look OK relative to Gtk it's incomplete (both are). That font: string in the bug179.rb is platform specific. 'mono bold 14' doesn't exist in the OSX/NSFont world by that name. I'm OK with using platform specific font names. If a Shoes developer really want this level of control of button appearance then they also have to do things for their platform of choice. Different font names applies to Windows too.

[IanTrudel]

Besides, a Shoes developer may want to include their own fonts with their app. Shoes is provided with two fonts already. Otherwise they may choose depending on the platform; this is what is done on web pages. Seems acceptable.

[ccoupe]

This is much better for OSX. If only gtk3 would behave. Oddly (?) there is no toolltip support - no code. Now would be good time to fix that while I'm in obj->C mode.

[ccoupe]

This just turned a bit ugly. The cocoa code was not written to make the visual buttons taller (or shorter) although it does layout with the proper size in Shoes space (osx space - maybe not) - Looks good but isn't good. It appears that the ShoesButton in cocoa does not properly subclass NSControl - we may need an initWithFrame: selector (aka method) to match cocoa's protocols. It's worth digging into but it's not going to be a speedy exploration.

[ccoupe]

I am also taking to time to refactor the cocoa.m file into individual widgets. @implementation section followed by the shoes/ruby code to create and call it. Will be much easier to set font, widget by widget.

[ccoupe]

Latest screen shots

[IanTrudel]

Looks like great work here. Shouldn't the buttons resize up when the content is too big?

[ccoupe]

Shouldn't the buttons resize up when the content is too big?

Many issues there :-) On Gtk you can set the height of the button (and it works). To do that on OSX requires a subclass of NSButtonCell (deprecated in 10.11) . I did find an interesting replacement at the SYFlatButton project but it won't compile for me. I left an issue there but haven't heard anything. Very obscure Objective-C. Newer Gtk3 (like freebsd ) does pack things a little differently so that's another issue - along with writing a gtkboxalt subclass to calm the chatter of warnings - there are warnings that gtk_box_new is headed for deprecation use gtk_grid instead -so we'd need a gtkaltgrid. All worth doing, someday (along with background color ability or even scaling images to fit.)

Shoes widgets don't change size based on content - they scale it down or clip it to fit the fixed size given at creation. To do otherwise would require another shoes_place_decide/layout engine - way outside the scope of this issue.

I'm going to move on to listbox since font setting on that seems to have been lost (and it needs moving out of gtk.c) and then setting fonts on other widgets w/o the icon/image problems.

[ccoupe]

I got gtk grid layout working well enough for buttons with text and images. freebsd screenshoot:

[IanTrudel]

This is an excellent addition to Shoes. It feels right with what Shoes is trying to accomplish.

By the way, you can get a better font rendering with LCD filtering (subpixel rendering) on FreeBSD.

[ccoupe]

This is an excellent addition to Shoes. It feels right with what Shoes is trying to accomplish.

I think so too. Other widgets need styling. osx need to match. A big H/T to @passenger94 for figuring out how to calm the gtk3 whining. We have much to do to finish his work with the 'alts'

By the way, you can get a better font rendering with LCD filtering (subpixel rendering) on FreeBSD.

So many problems, poking X and fonts on bsd is a low priority for me. Its a good test bed because it's fast and too tied to newer gtk3 problems. That's all.

[ccoupe]

Somehow bsd got broken. It crashes early in the shoes startup (pre splash screen). . Linux still works. Go figure, Sigh. Looking at the other widgets I see

• listbox could use stroke (font and stroke for osx) font is current supported on Gtk
• editbox could use font, stroke
• editline could use font, stroke
• slider could use font, stroke
• switch - could use two sets of font,stroke,icon. And ttile strings . Overkill?

[ccoupe]

Gtk Combo: aka list_box Gtk edit_line

[ccoupe]

Another road block. edit_box and others uses deprecated calls (gtk 3.16+) so I thought I'd look into the future proof css way. edit_box is a GtkTextView. Gnome doc/example says to do this but that doesn't work and I haven't found the net wisdom that helps. Of course, it could be a bug in my older Gtk3 implementation but a 3 year old Linux is not an ancient platform.

[IanTrudel]

Interesting that you mention CSS because I always thought Shoes had some kind of CSS in mind but never really fully implemented it.

[ccoupe]

I'm sure Shoes was influenced by css and other web technologies. I'm not sure letting app developers override platform themes is a good idea, cross platform . If you just code for a set of (say) Windows users then it 's a good feature. If the latter, we need to get the 'future proof' css thing working.

Forgot to mention, it fails on Windows which is a slightly newer gtk3.

[IanTrudel]

Here is a bug with text overflowing in a button. Seems to be relevant to this issue, somehow.

Shoes.app(width: 250, height: 100) do
  button("multiline\nbutton", left: 50, top: 25) do
    alert("does it work?")
  end
end

[ccoupe]

You're looking at a partial implementation of #179 that made it's way into the master branch. On Gtk based system you can set the height of the button. OSX - not yet.

[IanTrudel]

Not urgent or anything. Discovered this while testing something else. I would expect Shoes to automatically adjust the button.

[ccoupe]

I would expect Shoes to automatically adjust the button.

Shoes has never done that - it would screwup the user specified positioning.

[IanTrudel]

Shoes has never done that - it would screwup the user specified positioning.

I am not feeling strongly about this. Though overflowing doesn't make any sense. Positioning in Shoes has its own problems. For example, widgets have the ability to be relative, buttons will be side-by-side if no position is given, but arts (cairo elements) totally cannot do that (even with stack and flow). It might be a feature.

It does make a good counter argument where widgets are expected to push things around anyway. So if someone uses a CR in a button label, they shouldn't mind the button resize to fit. Just saying.

[ccoupe]

We have had the discussion before. We need a different layout manager/paradigm and that's a lot of work. Enough work, it might be easier to start from scratch and not call it Shoes. or Use wx-wdiget with a nicer ruby dsl.

[IanTrudel]

We have had the discussion before. We need a different layout manager/paradigm and that's a lot of work. Enough work, it might be easier to start from scratch and not call it Shoes. or Use wx-wdiget with a nicer ruby dsl.

How about we open an issue for this? Not something to be done anytime soon and perhaps never but talking may get us somewhere along the road. I am interested in your view and take on the subject. Besides, the current layout manager is somehow poorly understood (and not properly documented). I just now realize Shoes arts are always using absolute position... after 3 years using Shoes.

[ccoupe]

OSX is sufficiently difficult about changing the height of buttons that I'm going to not attempt it. A high amount of work with no demand and it looks ugly on Gtk3 and uglier on OSX - should it work and it doesn't.

[ccoupe]

Major Progress on this issue: Edit_line: Edit_box List_box Switch

OSX is good for edit_line, edit_box, no_show for list_box and yet to be done for switcj.

[dredknight]

This is awesome!

[ccoupe]

@dredknight , there is a Windows beta if you want to play with it.

[ccoupe]

OSX is equal to Gtk edit_line edit_box list_box switch: button:

As the manual says, button height doesn't work on OSX.

[dredknight]

Definitely something that will be used for the next skillwheel update!