> * What we are doing here is still heavily experimental. I don't think we know exactly where we are going yet, just trying to find out. I posted on the list so early > because I think it's important to get feedback. >* I think we have a bit of a different perspective. It seems like the goal of your framework is to add the ability to write html activities for the sugar platform, possibly > mixing with python code.
Okay. But it's interesting to have a look on today and tomorrow at the same time. So, my idea is to see how HTML activities developed today could work (or could be easily adapted) tomorrow. > We also have that goal but, in addition, we would like to provide the ability to write fully cross-platform activities. That could run for example on Android, on iOS, or > inside a web browser. So we are talking about a toolkit which is completely independent from the gtk3 one. It make sense. >>> * Toolbar widget using the icons API, perhaps without palettes. >> >> Yes but we should allow developers to use a true Python toolbar >> instead of the simple one when needed. > > I'm going back and forward on this. Of course I see why it's a required feature from your point of view... But if we provide an html toolbar implementation with all the > features of the gtk one, why would developers use the gtk one for an html activity? Maybe as an intermediate point while migrating from python to html, but I can't > think of other reasons. Right. >> * Datastore saving and loading. > > Again a lot of back an forward on this. I initially thought to implement those API with client side message passing (taking inspiration from your work). Then I've seen it's > implemented using the console-message signal, which doesn't really feel right. You're right, using "console-message" is not a perfect solution. But coupled with JSON serialization, it's a really easy way to ensure communication from JavaScript to Python (communication from Python to JavaScript use the WebView method "execute-script"). To be honest, I didn't find another way to do that. I wonder if there is a better way, for example what is the PhoneGap way to do this. > I think it's a functionality that might make sense to add to webkit gtk in a cleaner way but... I'm not sure it's worth if we have a server running anyway. It adds one more > requirement for the rendering engine we are using. Also it would be pretty nice to the have the whole sugar-toolkit-html implemented in javascript, rather than mixing > with python. Yes but porting Gtk is a huge amount of work. > And nodejs allows us to do that. The downside of course is the overhead of out process http communication. And adding nodejs add one more complexity. > I disagree on this. I think Sugar visual design is one if it's strong points and it should be retained. I also think all the activities should have a consistent visual appearance. There is no so much control in Sugar. Plus, most activities are graphical activities so, most activities use very few widgets. May be it could be sufficient to just give some guidelines about UI: do rounded button, use a specific font, ... Using these guidelines it will be easy for developers to be consistent with any JavaScript framework. > While it's not required I think a system wide html server is a good idea. It gives more flexibility than using file://. I really need to articulate this better (in my mind too) > but for example I would like to provide system icons by just specifying them as a path. Yes you're right but adding a HTTP server just to share icons is very expansive! > Thanks! Thanks to you. I'm happy to contribute. Lionel. _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel