V2 Updates

[Gabriel Csapo]

Just wondering what the V2 updates should look like, right now I have

• add events to all widgets
• add examples for all widgets

[Russell Keith-Magee]

 I haven't really got a fixed plan for what needs to be in the next release. My only vague thought was to try and port a tool like Cricket [1]; once the widget set is rich enough to support the needs of that app on OS/X and Linux, call that the next release.

The other thing I'm looking at doing for the next release is to possibly replace constraint-based layout. I originally picked it because it was native on OSX/iOS, and I was able to build an implementation for GTK. However, I've got some feedback that it's a bit hard to understand, and my own experience is that when it works, it's great, but when it doesn't, it's a PITA to debug - especially when the flaw lies with discrepancies in the algorithm between iOS and GTK. 

Interestingly, Facebook may have provided an alternative - they use an implementation of CSS FlexBox for React Native. I'm still tinkering, but I suspect it might provide a slightly more intuitive way of performing layout. I've already ported the flex box algorithm; I'm hoping to get it to the point where I can lay out an app over the weekend. Once I've got something working, I'd be interested in your feedback.

Russ %-)

[1] http://pybee.org/cricket

[Gabriel Csapo]

I can guarantee that we will have a full gui set within the next month with all the widget events and such. Cricket could be ported once that is done.

I am making examples with the contained based layout and also see it is pretty easy to understand, but is hard to get certain results, this could be overcome by making some widgets that have constraints built in that have underlying functions that making auto layouts easier? 

Yeah I just saw the release of React Native and it looks interesting, but still falls short when it comes to maintaining code and functionality. The layout functionality is helpful. 

I think the idea of a model library to accompany basic data bindings for all toga gui libraries would be helpful in the future. 

[Gabriel Csapo]

currently working on this repo https://github.com/gabrielcsapo/toga-cocoa. I am falling into what else to add mode, any suggestions would be great. 

[Russell Keith-Magee]

I've just taken a look at your branch. You've done a lot of work here, much of it great - but there's a few missteps IMHO, too. Here's my initial comments:

 * The new examples directory is great; if nothing else, it's a good starting point for the gallery of widgets.

 * I don't know if it's intentional or accidental, but you've completely restructured the repository, dropping all the top level LICENSE, setup.py, etc. This makes a direct diff more difficult than it should be.

 * You appear to have duplicated the contents of rubicon.objc, rather than just having that library in your PYTHONPATH - again, it makes a diff much harder than it should be

 * In terms of naming style: Python convention is set_method_with_underscore(), not setCamelCase(). This is particularly noticeable in you changes to on the Button widget.

 * On the subject of the button widget; it looks like you've done a feature-for-feature mapping of the capabilities of the Cocoa button widget - in particular, the fact that there is only one "button", which a bunch of modes on it (toggle, radio, momentary press, etc). That's not the approach I want to take with Toga. Instead, I want to have a bunch of independent widgets which represents the set of functionality that makes sense in a broader context, and is available across multiple platforms. In many cases, this will mean a Cocoa widget that is a very simple subclass of a base button that flicks an flag on the impl - but the point is to provide a consistent cross-platform API. The roadmap contains an initial survey of the widgets I think need to exist, with proposed names:

http://toga.readthedocs.org/en/latest/internals/roadmap.html

I'm certainly up for discussion about the content of this roadmap, but I hope the intention of that document is clear.

 * "SplitContainer" was a deliberate choice of name over "SplitView" - I'm trying to make a clear distinction between Views as something that displays data, and Containers, and something that holds other views.

 

 * Calls to get_NSString() (e.g., in app.py) shouldn't be required if you're using Rubicon; the conversion of text objects (unicode on Py2, str on Py3) to NSString should be automatic. I suspect part of the problem may be that you've dropped the unicode_literals __future__ import; are you running on Python 2 or Python 3?

As an aside; over the weekend, I've been tinkering with CSS-based layout over the weekend (as inspired by React Native); my initial experiments suggest to me that it might be a lot more compelling (and easier to maintain) that constraint-based layout. The reason I mention this is that it affects the examples directory fairly significantly; it also has an impact on widget implementations (nothing major, but some notable changes). I'm hoping to push an exploratory branch later this afternoon (my time).

Yours,

Russ Magee %-)

On Sun, Mar 29, 2015 at 3:47 AM, Gabriel Csapo <gabe...@gmail.com> wrote:

currently working on this repo https://github.com/gabrielcsapo/toga-cocoa. I am falling into what else to add mode, any suggestions would be great. 

--
You received this message because you are subscribed to the Google Groups "Beeware Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beeware-develop...@googlegroups.com.
To post to this group, send email to beeware-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/beeware-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/beeware-developers/c242bb88-9bb8-4baf-ba0b-5101f24dec98%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Gabriel Csapo]

Hey Russell,

On Saturday, March 28, 2015 at 10:49:13 PM UTC-4, Russell Keith-Magee wrote:

I've just taken a look at your branch. You've done a lot of work here, much of it great - but there's a few missteps IMHO, too. Here's my initial comments:

 * The new examples directory is great; if nothing else, it's a good starting point for the gallery of widgets.

 * I don't know if it's intentional or accidental, but you've completely restructured the repository, dropping all the top level LICENSE, setup.py, etc. This makes a direct diff more difficult than it should be.

 

 I apologize for the directory mixup. I have been editing the installed version of toga_cooca located in site-packages.

 I am refactoring to fix the problems that have come because of that. 

 

 * You appear to have duplicated the contents of rubicon.objc, rather than just having that library in your PYTHONPATH - again, it makes a diff much harder than it should be

 

part of the problem with me editing the installed version 

 * In terms of naming style: Python convention is set_method_with_underscore(), not setCamelCase(). This is particularly noticeable in you changes to on the Button widget.

 

will adhere to python convention, I use multiple languages throughout the day, semantics with dealing such things. 

 * On the subject of the button widget; it looks like you've done a feature-for-feature mapping of the capabilities of the Cocoa button widget - in particular, the fact that there is only one "button", which a bunch of modes on it (toggle, radio, momentary press, etc). That's not the approach I want to take with Toga. Instead, I want to have a bunch of independent widgets which represents the set of functionality that makes sense in a broader context, and is available across multiple platforms. In many cases, this will mean a Cocoa widget that is a very simple subclass of a base button that flicks an flag on the impl - but the point is to provide a consistent cross-platform API. The roadmap contains an initial survey of the widgets I think need to exist, with proposed names:

http://toga.readthedocs.org/en/latest/internals/roadmap.html

I'm certainly up for discussion about the content of this roadmap, but I hope the intention of that document is clear.

Could there be a breakdown of specific types of elements, for example you say switch which is a subclass of button. Right now in the button class I have

• basic_button
  
• momentary_button
  
• toggle_button
  
• switch_button
  
• radio_button
  
• momentary_change_button
  
• on_off_button
  
• momentary_pushin_button 
  

You mention the roadmap which includes multiple UI elements structured by input, view and containers but I see a discrepancy in the way you structured this.

You mention table in the input section with the line "Table: A scrollable display of columns of data", but then in the view section you say "views are mechanisms for displaying rich content, usually in a readonly manner", in this case a table is a view and also an input. 

 * "SplitContainer" was a deliberate choice of name over "SplitView" - I'm trying to make a clear distinction between Views as something that displays data, and Containers, and something that holds other views.

I saw this as a semantic change, since the actual element in cocoa is called NSSplitView, also in WPF land it is referred to as SplitView as well (https://channel9.msdn.com/Series/Developers-Guide-to-Windows-10-Preview/05)*SplitView Control*. I now understand that change to make that clear on your side. 

 

 * Calls to get_NSString() (e.g., in app.py) shouldn't be required if you're using Rubicon; the conversion of text objects (unicode on Py2, str on Py3) to NSString should be automatic. I suspect part of the problem may be that you've dropped the unicode_literals __future__ import; are you running on Python 2 or Python 3?

This was the problem I brought up in an early post with get_NSString() not working when using the Rubicon version, but when using the objc.py file, which comes with the install of toga_cocoa it works perfectly. 

 

As an aside; over the weekend, I've been tinkering with CSS-based layout over the weekend (as inspired by React Native); my initial experiments suggest to me that it might be a lot more compelling (and easier to maintain) that constraint-based layout. The reason I mention this is that it affects the examples directory fairly significantly; it also has an impact on widget implementations (nothing major, but some notable changes). I'm hoping to push an exploratory branch later this afternoon (my time).

I for one thing that this should be choice, in windows you have a choice to choose between multiple layout managers, and I think that is really useful. Constrained based layouts are flexible and easy to read, looking at the CSS-based layouts that you are talking about, there is a lot of code to explain the same output. For example if someone wanted to have a 'btn-block' like in bootstrap world, that is easy with a constrained layout;

container = toga.Container()

basic_button = toga.Button("Basic Button")

container.add(basic_button)

container.constrain(basic_button.RIGHT == container.RIGHT - 5)

container.constrain(basic_button.LEFT == container.LEFT + 5)

To accomplish the same with CSS-based layout

container = toga.Container()

container container.style(flexDirection='row', margin=5)

basic_button = toga.Button("Basic Button")

container.add(basic_button)

basic_button.style(width:100%)

I am unsure if width is just a pixel based ratio, or it has the ability to be a percentage. I also don't want you to think I am against the idea, if it was just as easy to markup native applications as web applications, I would be all for it, but the styling is not done on the elements themselves, it is done by a CSS file which then is passed into the browser and renders the elements into their proper proportions and other attributes (color, text). If there was someone to emulate that experience, it might be an interesting proposition.

Yours,

Russ Magee %-)

On Sun, Mar 29, 2015 at 3:47 AM, Gabriel Csapo <gabe...@gmail.com> wrote:

currently working on this repo https://github.com/gabrielcsapo/toga-cocoa. I am falling into what else to add mode, any suggestions would be great. 

--
You received this message because you are subscribed to the Google Groups "Beeware Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beeware-developers+unsub...@googlegroups.com.

To unsubscribe from this group and stop receiving emails from it, send an email to beeware-developers+unsub...@googlegroups.com.

To post to this group, send email to beeware-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/beeware-developers.

[Russell Keith-Magee]

On Mon, Mar 30, 2015 at 12:19 AM, Gabriel Csapo <gabe...@gmail.com> wrote:

Hey Russell,

On Saturday, March 28, 2015 at 10:49:13 PM UTC-4, Russell Keith-Magee wrote:

I've just taken a look at your branch. You've done a lot of work here, much of it great - but there's a few missteps IMHO, too. Here's my initial comments:

 * The new examples directory is great; if nothing else, it's a good starting point for the gallery of widgets.

 * I don't know if it's intentional or accidental, but you've completely restructured the repository, dropping all the top level LICENSE, setup.py, etc. This makes a direct diff more difficult than it should be.

 

 I apologize for the directory mixup. I have been editing the installed version of toga_cooca located in site-packages.

 I am refactoring to fix the problems that have come because of that. 

 

 * You appear to have duplicated the contents of rubicon.objc, rather than just having that library in your PYTHONPATH - again, it makes a diff much harder than it should be

 

part of the problem with me editing the installed version 

Do you know about pip install -e? Run this in the root of a Python source directory (i.e., a directory with setup.py), and it will "install" your source directory into site_packages, but allow you to keep editing the source exactly where it is checked out.

 * In terms of naming style: Python convention is set_method_with_underscore(), not setCamelCase(). This is particularly noticeable in you changes to on the Button widget.

 

will adhere to python convention, I use multiple languages throughout the day, semantics with dealing such things. 

 

 * On the subject of the button widget; it looks like you've done a feature-for-feature mapping of the capabilities of the Cocoa button widget - in particular, the fact that there is only one "button", which a bunch of modes on it (toggle, radio, momentary press, etc). That's not the approach I want to take with Toga. Instead, I want to have a bunch of independent widgets which represents the set of functionality that makes sense in a broader context, and is available across multiple platforms. In many cases, this will mean a Cocoa widget that is a very simple subclass of a base button that flicks an flag on the impl - but the point is to provide a consistent cross-platform API. The roadmap contains an initial survey of the widgets I think need to exist, with proposed names:

http://toga.readthedocs.org/en/latest/internals/roadmap.html

I'm certainly up for discussion about the content of this roadmap, but I hope the intention of that document is clear.

Could there be a breakdown of specific types of elements, for example you say switch which is a subclass of button. Right now in the button class I have

• basic_button
  
• momentary_button
  
• toggle_button
  
• switch_button
  
• radio_button
  
• momentary_change_button
  
• on_off_button
  
• momentary_pushin_button 

Well, there *is* a partial (and admittedly incomplete) breakdown already - there's Button and Switch for example. 

The key distinction I'm trying to make is that I'm not just trying to enumerate "widgets that are available on an underlying platform", but "widgets for which there is a distinct UI/UX purpose".  

I will admit that the roadmap is incomplete - the omission of radio buttons, for example, is a clear oversight on my part. So why does a RadioSelection widget deserve to exist? And, to be clear - it's a RadioSelection, not a standalone RadioButton, because there's no reason to put a single RadioButton on a GUI without a label, and at least one other RadioButton. When do you use RadioSelection and when do you use Selection? You use RadioSelection when the number of options is small and fixed. You use Selection when the list of options is long, or can vary depending on other application context. Reflecting this distinction, there's probably a better name than RadioSelection and Selection, too.

As supporting evidence, a Radio button widget is available on OSX, GTK+ and Windows. This existence proof is a demonstration that multiple UI teams have made the UI distinction, but it's not, IMHO, prima facie proof that a Toga widget is required. 

As a counterpoint, I *don't* see a fundamental reason why there needs to be a Switch, OnOff and Checkbox widget. A toga.Switch is something you use to toggle something that has an on/off option state. You'll note that on the roadmap, Switch is listed as an NSButton with checkbox style on OSX, but an UISwitch on OS/X - that's because the interaction metaphors on the two platforms are different. The only times I've seen a true "on/off" Switch on OS/X has been for showy reasons, where it is (arguably) inconsistent UI/UX. 

So - the fundamental question to be asked is "What is the UX reason for having multiple alternatives?" What's the UX difference between a checkbox and a switch? As a minimum barrier to entry, you need to be able to put in the documentation a UX explanation for when you use widget A instead of B. If you can make that argument for any of your other button types, I'll happily accept them. 

You mention the roadmap which includes multiple UI elements structured by input, view and containers but I see a discrepancy in the way you structured this.

You mention table in the input section with the line "Table: A scrollable display of columns of data", but then in the view section you say "views are mechanisms for displaying rich content, usually in a readonly manner", in this case a table is a view and also an input. 

 

That's a fair point. In retrospect, I'd agree that Tree and Table are probably closer to View than Input. If there's an Input aspect to those widgets, it is at the level of an individual row or cell in the view. Tree and Table should probably be renamed to TreeView and TableView.

 

 * "SplitContainer" was a deliberate choice of name over "SplitView" - I'm trying to make a clear distinction between Views as something that displays data, and Containers, and something that holds other views.

I saw this as a semantic change, since the actual element in cocoa is called NSSplitView, also in WPF land it is referred to as SplitView as well (https://channel9.msdn.com/Series/Developers-Guide-to-Windows-10-Preview/05)*SplitView Control*. I now understand that change to make that clear on your side. 

 

 * Calls to get_NSString() (e.g., in app.py) shouldn't be required if you're using Rubicon; the conversion of text objects (unicode on Py2, str on Py3) to NSString should be automatic. I suspect part of the problem may be that you've dropped the unicode_literals __future__ import; are you running on Python 2 or Python 3?

This was the problem I brought up in an early post with get_NSString() not working when using the Rubicon version, but when using the objc.py file, which comes with the install of toga_cocoa it works perfectly.  

I'm definitely interested in seeing this reduced to a pure ObjC example - because I can't see any reason it shouldn't work as advertised. 

 

As an aside; over the weekend, I've been tinkering with CSS-based layout over the weekend (as inspired by React Native); my initial experiments suggest to me that it might be a lot more compelling (and easier to maintain) that constraint-based layout. The reason I mention this is that it affects the examples directory fairly significantly; it also has an impact on widget implementations (nothing major, but some notable changes). I'm hoping to push an exploratory branch later this afternoon (my time).

I for one thing that this should be choice, in windows you have a choice to choose between multiple layout managers, and I think that is really useful.

IMHO - the reason other widget toolkits provide multiple options is because the layout mechanisms they've provided aren't useful in the generic sense. Almost every widget toolkit I've ever used, with the exception of constraint-based Autolayout on OSX and iOS, provides multiple "box models" (hbox, vbox, various versions of grid, etc) because no single simple box layout can let you lay out everything you want. 

OS/X and iOS *only* provide auto layout (well... auto layout, legacy spring layouts, and "100% manual define it yourself layout"), because on paper, you can make any layout possible with the right constraints. The trick is finding the right constraints.

It's worth noting that HTML doesn't provide multiple layout mechanisms, either. It only provides CSS. Admittedly, the CSS1 box model is brain dead, but over time, the box model has improved. With CSS3 and flexBox, we're finally at the point where some of the really obvious things that people want to do (like vertical alignment) have a first-class representation in CSS syntax. 

And - at the end of the day, if you *do* want to manage layout yourself, CSS does provide that option - "position:absolute; top:10; left:10; width:100; height:50". Making truly customised layout a viable option would require documenting the mechanism for intercepting the re-layout request (currently widget._update_layout()); but given the right hooks, but it should be possible to layer a constraint-based layout scheme over the top of CSS. As partial proof, see http://gridstylesheets.org - that's Cassowary layered over the top of CSS for the web.

 

Constrained based layouts are flexible and easy to read, looking at the CSS-based layouts that you are talking about, there is a lot of code to explain the same output. For example if someone wanted to have a 'btn-block' like in bootstrap world, that is easy with a constrained layout;

container = toga.Container()

basic_button = toga.Button("Basic Button")

container.add(basic_button)

container.constrain(basic_button.RIGHT == container.RIGHT - 5)

container.constrain(basic_button.LEFT == container.LEFT + 5)

To accomplish the same with CSS-based layout

container = toga.Container()

container container.style(flexDirection='row', margin=5)

basic_button = toga.Button("Basic Button")

container.add(basic_button)

basic_button.style(width:100%)

Well... to my count, that's the same number of lines of code, and *less* bytes... and that's allowing for an over specified CSS example - the outer container is *required* for Cassowary (because you need a widget to bind to), but isn't strictly required for the CSS example, because you can just specify the margin, and boxes default to 100% unless otherwise specified.

 

I am unsure if width is just a pixel based ratio, or it has the ability to be a percentage. I also don't want you to think I am against the idea, if it was just as easy to markup native applications as web applications, I would be all for it, but the styling is not done on the elements themselves, it is done by a CSS file which then is passed into the browser and renders the elements into their proper proportions and other attributes (color, text). If there was someone to emulate that experience, it might be an interesting proposition.

At the moment, width/height are purely pixel based. There is also "weight sharing" through the flex box algorithm (so you can say "these three widgets are all the same size", or "these three widgets all share size but widget A is twice the size of B and C"). However, this is a limitation of the implementation, not the fundamental approach. The interaction of pixel and percentage layouts is well defined by the CSS specification; colosseum just doesn't implement that part of the CSS spec yet.

Well, that's not strictly true - you *can* specify style on individual elements, and the external style sheet is then used as a base style. I hadn't considered this approach, but conceptually, I can see that it is a possibility - if you provide an ID and CLASS attribute with which to target 

Going all the way down the rabbit hole, it should be possible to define an entire UI in a text-based syntax (e.g., an XML <container><button onPress="do_stuff">Hello World</button></container>, with separate CSS targeting of styles "button {padding=5;}"). Then you're just replacing the build() method for an app with a "read the UI specification" method. Interestingly, this is similar to what Qt has moved towards (although, not with XML). It's also a step that would make a GUI-layout tool much easier.

Yours,

Russ Magee %-)

[Gabriel Csapo]

On Sunday, March 29, 2015 at 11:20:39 PM UTC-4, Russell Keith-Magee wrote:

On Mon, Mar 30, 2015 at 12:19 AM, Gabriel Csapo <gabe...@gmail.com> wrote:

Hey Russell,

On Saturday, March 28, 2015 at 10:49:13 PM UTC-4, Russell Keith-Magee wrote:

I've just taken a look at your branch. You've done a lot of work here, much of it great - but there's a few missteps IMHO, too. Here's my initial comments:

 * The new examples directory is great; if nothing else, it's a good starting point for the gallery of widgets.

 * I don't know if it's intentional or accidental, but you've completely restructured the repository, dropping all the top level LICENSE, setup.py, etc. This makes a direct diff more difficult than it should be.

 

 I apologize for the directory mixup. I have been editing the installed version of toga_cooca located in site-packages.

 I am refactoring to fix the problems that have come because of that. 

 

 * You appear to have duplicated the contents of rubicon.objc, rather than just having that library in your PYTHONPATH - again, it makes a diff much harder than it should be

 

part of the problem with me editing the installed version 

Do you know about pip install -e? Run this in the root of a Python source directory (i.e., a directory with setup.py), and it will "install" your source directory into site_packages, but allow you to keep editing the source exactly where it is checked out.

Thank you, I did not know about that, will remember this!

 

 * In terms of naming style: Python convention is set_method_with_underscore(), not setCamelCase(). This is particularly noticeable in you changes to on the Button widget.

 

will adhere to python convention, I use multiple languages throughout the day, semantics with dealing such things. 

 

 * On the subject of the button widget; it looks like you've done a feature-for-feature mapping of the capabilities of the Cocoa button widget - in particular, the fact that there is only one "button", which a bunch of modes on it (toggle, radio, momentary press, etc). That's not the approach I want to take with Toga. Instead, I want to have a bunch of independent widgets which represents the set of functionality that makes sense in a broader context, and is available across multiple platforms. In many cases, this will mean a Cocoa widget that is a very simple subclass of a base button that flicks an flag on the impl - but the point is to provide a consistent cross-platform API. The roadmap contains an initial survey of the widgets I think need to exist, with proposed names:

http://toga.readthedocs.org/en/latest/internals/roadmap.html

I'm certainly up for discussion about the content of this roadmap, but I hope the intention of that document is clear.

Could there be a breakdown of specific types of elements, for example you say switch which is a subclass of button. Right now in the button class I have

• basic_button
  
• momentary_button
  
• toggle_button
  
• switch_button
  
• radio_button
  
• momentary_change_button
  
• on_off_button
  
• momentary_pushin_button 

Well, there *is* a partial (and admittedly incomplete) breakdown already - there's Button and Switch for example. 

The key distinction I'm trying to make is that I'm not just trying to enumerate "widgets that are available on an underlying platform", but "widgets for which there is a distinct UI/UX purpose".  

I will admit that the roadmap is incomplete - the omission of radio buttons, for example, is a clear oversight on my part. So why does a RadioSelection widget deserve to exist? And, to be clear - it's a RadioSelection, not a standalone RadioButton, because there's no reason to put a single RadioButton on a GUI without a label, and at least one other RadioButton. When do you use RadioSelection and when do you use Selection? You use RadioSelection when the number of options is small and fixed. You use Selection when the list of options is long, or can vary depending on other application context. Reflecting this distinction, there's probably a better name than RadioSelection and Selection, too.

As supporting evidence, a Radio button widget is available on OSX, GTK+ and Windows. This existence proof is a demonstration that multiple UI teams have made the UI distinction, but it's not, IMHO, prima facie proof that a Toga widget is required. 

As a counterpoint, I *don't* see a fundamental reason why there needs to be a Switch, OnOff and Checkbox widget. A toga.Switch is something you use to toggle something that has an on/off option state. You'll note that on the roadmap, Switch is listed as an NSButton with checkbox style on OSX, but an UISwitch on OS/X - that's because the interaction metaphors on the two platforms are different. The only times I've seen a true "on/off" Switch on OS/X has been for showy reasons, where it is (arguably) inconsistent UI/UX. 

So - the fundamental question to be asked is "What is the UX reason for having multiple alternatives?" What's the UX difference between a checkbox and a switch? As a minimum barrier to entry, you need to be able to put in the documentation a UX explanation for when you use widget A instead of B. If you can make that argument for any of your other button types, I'll happily accept them. 

I think this is a valid argument, but if you are looking for a native GUI, different OS's have different ways of visualizing that GUI. A switch is a basic GUI element for OSX and iOS, for windows a I don't know if I have ever seen a switch, but instead have seen a checkbox to visualize that. I don't think it is a a right direction to go in if the main argument is to omit GUI elements because they don't exist in all platforms.

 

You mention the roadmap which includes multiple UI elements structured by input, view and containers but I see a discrepancy in the way you structured this.

You mention table in the input section with the line "Table: A scrollable display of columns of data", but then in the view section you say "views are mechanisms for displaying rich content, usually in a readonly manner", in this case a table is a view and also an input. 

 

That's a fair point. In retrospect, I'd agree that Tree and Table are probably closer to View than Input. If there's an Input aspect to those widgets, it is at the level of an individual row or cell in the view. Tree and Table should probably be renamed to TreeView and TableView.

I will update the documentation to reflect this.

I really think that way of defining a GUI is a lot easier to do then the current model. Basically like HTML for marking up native GUI. 

 

Yours,

Russ Magee %-)

[Russell Keith-Magee]

On Tue, Mar 31, 2015 at 12:19 AM, Gabriel Csapo <gabe...@gmail.com> wrote:

On Sunday, March 29, 2015 at 11:20:39 PM UTC-4, Russell Keith-Magee wrote:

On Mon, Mar 30, 2015 at 12:19 AM, Gabriel Csapo <gabe...@gmail.com> wrote:

Hey Russell,

On Saturday, March 28, 2015 at 10:49:13 PM UTC-4, Russell Keith-Magee wrote:

 * On the subject of the button widget; it looks like you've done a feature-for-feature mapping of the capabilities of the Cocoa button widget - in particular, the fact that there is only one "button", which a bunch of modes on it (toggle, radio, momentary press, etc). That's not the approach I want to take with Toga. Instead, I want to have a bunch of independent widgets which represents the set of functionality that makes sense in a broader context, and is available across multiple platforms. In many cases, this will mean a Cocoa widget that is a very simple subclass of a base button that flicks an flag on the impl - but the point is to provide a consistent cross-platform API. The roadmap contains an initial survey of the widgets I think need to exist, with proposed names:

http://toga.readthedocs.org/en/latest/internals/roadmap.html

I'm certainly up for discussion about the content of this roadmap, but I hope the intention of that document is clear.

Could there be a breakdown of specific types of elements, for example you say switch which is a subclass of button. Right now in the button class I have

• basic_button
  
• momentary_button
  
• toggle_button
  
• switch_button
  
• radio_button
  
• momentary_change_button
  
• on_off_button
  
• momentary_pushin_button 

Well, there *is* a partial (and admittedly incomplete) breakdown already - there's Button and Switch for example. 

The key distinction I'm trying to make is that I'm not just trying to enumerate "widgets that are available on an underlying platform", but "widgets for which there is a distinct UI/UX purpose".  

I will admit that the roadmap is incomplete - the omission of radio buttons, for example, is a clear oversight on my part. So why does a RadioSelection widget deserve to exist? And, to be clear - it's a RadioSelection, not a standalone RadioButton, because there's no reason to put a single RadioButton on a GUI without a label, and at least one other RadioButton. When do you use RadioSelection and when do you use Selection? You use RadioSelection when the number of options is small and fixed. You use Selection when the list of options is long, or can vary depending on other application context. Reflecting this distinction, there's probably a better name than RadioSelection and Selection, too.

As supporting evidence, a Radio button widget is available on OSX, GTK+ and Windows. This existence proof is a demonstration that multiple UI teams have made the UI distinction, but it's not, IMHO, prima facie proof that a Toga widget is required. 

As a counterpoint, I *don't* see a fundamental reason why there needs to be a Switch, OnOff and Checkbox widget. A toga.Switch is something you use to toggle something that has an on/off option state. You'll note that on the roadmap, Switch is listed as an NSButton with checkbox style on OSX, but an UISwitch on OS/X - that's because the interaction metaphors on the two platforms are different. The only times I've seen a true "on/off" Switch on OS/X has been for showy reasons, where it is (arguably) inconsistent UI/UX. 

So - the fundamental question to be asked is "What is the UX reason for having multiple alternatives?" What's the UX difference between a checkbox and a switch? As a minimum barrier to entry, you need to be able to put in the documentation a UX explanation for when you use widget A instead of B. If you can make that argument for any of your other button types, I'll happily accept them. 

I think this is a valid argument, but if you are looking for a native GUI, different OS's have different ways of visualizing that GUI. A switch is a basic GUI element for OSX and iOS, for windows a I don't know if I have ever seen a switch, but instead have seen a checkbox to visualize that. I don't think it is a a right direction to go in if the main argument is to omit GUI elements because they don't exist in all platforms. 

To be clear - given that a widget exists on a particular platform, there are two possible outcomes:

 1) Identify that the widget is redundant on the platform where it is available. If you can't articulate a UX reason why you need both a switch *and* a checkbox, then there's no reason to have both. One of the controls is either redundant, or exists for legacy reasons on the platform. 

 2) Identify that it's an omission on other platforms. Lets say we *can* articulate a UX distinction between switch and checkbox. Windows doesn't provide a standard switch control (that I'm aware of), so we would need to have 2 Toga controls that both implement checkbox - that is, two Toga controls that use the same underlying Windows control.  This would ensure that Windows users can handle both UX scenarios.

One of the roles of frameworks is to be opinionated. One of the opinions I'm enforcing is that Toga isn't *just* a light wrapper around underlying widgets; it applies a semantic layer over the top. The cost of this is that it won't always be a direct 1-1 mapping of all available widgets to all available platforms. I don't want to end up in a situation where an app won't run on Windows because Windows doesn't provide a Switch widget; I want the app designer to think about their purpose, pick an appropriate control, and know that this control is available everywhere.

Yours,

Russ Magee %-)

[Gabriel Csapo]

So just to be clear Toga is a cross platform GUI library that has consistent widgets regardless of their role being native to a certain platform or not?

[Russell Keith-Magee]

It's a cross platform GUI library, with a consistent set of *semantic* capabilities, each rendered using system-appropriate native widgets. 

Picking on the Switch/checkbox example again: Toga *doesn't* have a "checkbox" widget. It has a "boolean choice" widget. On OS/X and Windows, this is rendered as a checkbox, because that's the appropriate widget to render a boolean decision on those platforms. On iOS, it's rendered as a switch, because *that's* the appropriate widget to render a boolean decision on iOS.

The reason there isn't a switch *and* a checkbox widget is because they both serve the same purpose - rendering a boolean decision (is feature X enabled or disabled). A checkbox widget on iOS would look out of place; while switch widgets aren't unheard of on OS/X, they're uncommon; I don't think Windows has a native switch widget.

However, *if* someone can present a good reason why there is a *semantic* distinction between a switch and a checkbox, I'd support adding a second widget. This would mean on OS/X, the 2 Toga widgets would render as different OS/X widgets; but on iOS, you'd get a switch widget for both, because a checkbox still isn't a native widget for iOS; and on Windows, both would be rendered as a checkbox, because a switch isn't a native widget.

Again - Toga is trying to capture the high level concepts, not the specifics on a particular platform's rendering. Does that make sense?

Yours

Russ Magee %-)

[Gabriel Csapo]

Got it. Code once, deploy everywhere. I was interested in abstracting cocoa objects into python, I did not know this was a project to make a tkinter or wxwidget replacement. 

[Russell Keith-Magee]

On Tue, Mar 31, 2015 at 9:42 AM, Gabriel Csapo <gabe...@gmail.com> wrote:

I understand your reasoning and this follows the same semantics that the Java GUI or Tkinter or GTK+ use, but when I read the headline of the library, my idea of native GUI just means an abstraction, not a inconvenience. 

The only reason I see this as being frustrating is debugging components on different operating systems. When I look at a tableview on OSX, I have the ability to go look up exactly what a tableview can do on that platform and design my application to understand those constraints by looking at native documentation and not having to abstract that to a concept where I have to do more work. 

This isn't just checkbox and switch widgets. OSX has different ways of representing the share menu, or accessing system level events, if your philosophy is build once deploy everywhere that was not explained when my initial thought of toga. I read "A Python native, OS native GUI toolkit. Part of the BeeWare suite."to that I thought being able to have a consistent programming style between platforms. 

I am sorry if this is wasting your time, I am just trying to understand the reasoning. 

No worries - if my point hasn't come across, then the fault lies mostly lies with myself being unclear in the way I've advertised the toolkit.

A lot of my underlying ideas are laid out in the project philosophy page - I think I've linked to this before, but just in case:

http://toga.readthedocs.org/en/latest/philosophy.html

Taking the "share menu" as an example - yes, OS/X does have it's own unique ways of representing the share menu. However, the underlying idea of "share this content with other apps" or "share this content with a cloud website" *isn't* OS-specific. My intention with the Toga API is to provide a high level *semantic* API, implemented in whatever native UX is appropriate, not to provide a low level down-to-the-metal API. 

The Java/Tkinter analogy is a good one, if only because I started Toga after a brief love affair with tkinter. Ultimately, tkinter let me down because of a lack of widgets (specifically a HTML view), with no obvious path for adding one. On top of that, I saw lots of opportunity to improve the basic app-construction experience (e.g., every app needs to define it's own basic menu structure, and as a programmer, you have to put a bunch of "if apple put the quit menu option on the App menu, not the File menu" logic. To me, this is boilerplate that should come out of the box.

GTK+, however, *isn't* a good analogy. On OS/X, GTK+ renders through X11, so it *really* doesn't look native; I haven't looked at GTK+ on Windows for a while, but last time I did look at it, it didn't use windows widgets - it used a theme to render windows-like widgets with GDK Pixbuf backing. Theming is something I'm very specifically against. Toga is native, in that it exposes actual native widgets, using native APIs internally. However, it doesn't expose those native APIs to the end user.

Yours

Russ Magee %-)

[Austin Hicks]

I'm just throwing this out there because it's why I never really contributed and this seems to be the same issue I had.  Why not define some abstract base classes that we inherit from in concordance with the roadmap and then disallow new controls without first defining an abstract base class for them?

It seems that this would avoid issues like this: as a backend maintainer/contributor, I know exactly what is expected because I am being told what the interface *must* look like.

Not sure if this is off topic for this thread, but I'm seeing a symptom of a potentially larger problem, so I figured I'd ask.

--
You received this message because you are subscribed to the Google Groups "Beeware Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beeware-develop...@googlegroups.com.

To post to this group, send email to beeware-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/beeware-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/beeware-developers/CAJxq84-P9z43qD7FkKfaLhTjY7yunQM0aQWad6oewhxwj_kb_Q%40mail.gmail.com.

[Russell Keith-Magee]

On Fri, Apr 3, 2015 at 7:58 AM, Austin Hicks <caml...@gmail.com> wrote:

I'm just throwing this out there because it's why I never really contributed and this seems to be the same issue I had.  Why not define some abstract base classes that we inherit from in concordance with the roadmap and then disallow new controls without first defining an abstract base class for them?

It seems that this would avoid issues like this: as a backend maintainer/contributor, I know exactly what is expected because I am being told what the interface *must* look like.

Not sure if this is off topic for this thread, but I'm seeing a symptom of a potentially larger problem, so I figured I'd ask.

 

There's three reasons I can think of:

1) I haven't got around to it yet, and it's easier to write a document with bullet points than a bunch of code. :-)

2) I'm wary of the extra complication while code is still under active development. For example, in order to move from Cassowary to CSS, I needed to change the constructor for each widget. If there's an abstract base class as well, then that's one more class that needs to be altered before you can test if an idea is any good. Once APIs settle down, this overhead will be a lot less.

3) I'm wary of having abstract base classes that don't do anything. At least at the moment, there's very little shared code between the various backends. That said, this is possibly a reflection of the maturity of the APIs; when there are more sophisticated APIs in place for widgets like Tree and Table, I'm sure there will be common code needed to support data model backing, etc.

Yours,

Russ Magee %-)

[Austin Hicks]

I was specifically talking about the abc module and the public interface.  I know code isn't shared, but I for one consider a method whose body is pass to be a "todo" item and, if nothing else, it forces me to have them.  At the moment, in order to be a backend maintainer, one ahs to be involved in some sort of converging interface process.  Or at least, that's what it looks like from the outside.

But maybe I'm in a minority for wanting to design this way.  And my primary language is C++, which probably says a lot.

--
You received this message because you are subscribed to the Google Groups "Beeware Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beeware-develop...@googlegroups.com.
To post to this group, send email to beeware-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/beeware-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/beeware-developers/CAJxq848gvAHqHGRqfzkrPo8XQU5btp%3DcLkzqt66FVQvH9rsepQ%40mail.gmail.com.

[Russell Keith-Magee]

On Mon, Apr 13, 2015 at 7:42 AM, Austin Hicks <caml...@gmail.com> wrote:

I was specifically talking about the abc module and the public interface.  I know code isn't shared, but I for one consider a method whose body is pass to be a "todo" item and, if nothing else, it forces me to have them.  At the moment, in order to be a backend maintainer, one ahs to be involved in some sort of converging interface process.  Or at least, that's what it looks like from the outside.

 

That's because the interface *is* still converging at the moment - we're still in the "fiddling with the API" phase of Toga development, and while you're fiddling, having lots of formality in place is more hindrance than help, in my experience.

But maybe I'm in a minority for wanting to design this way.  And my primary language is C++, which probably says a lot.

 

There's at least a little bit of language culture involved in this. C++ is compiled, and won't let you do anything until everything is tied down and formalised. Python tends towards "duck typing" - if an object quacks like a duck, Python will let you treat it like a duck. 

In terms of end runtime behavior, there wouldn't be that much difference between having an ABC or not; as it stands, if you have a widget that doesn't define a known method, you'll get an AttributeError because the method doesn't exist. If we *had* an ABC, you'd get a NotImplemented exception. But in both cases, you'd get that at runtime. The only benefit of having the ABC is a clearly "documented-by-code" list of all the methods you need to implement as part of the formal interface. I admit that in the longer term, this may be useful; but in the meantime, it's one more piece of furniture to be moving around while you're trying to work out what the actual list of formal methods should be.

Yours,

Russ Magee %-)