Sam, You don't loose all the space, because you don't need a fixed toolbar in the server. Is content, and the content will scroll.
Gonzalo On Tue, Apr 21, 2015 at 7:27 PM, Sam P. <sam.parkins...@gmail.com> wrote: > Hi Gonzalo, > > On Tue, Apr 21, 2015 at 9:29 PM Gonzalo Odiard <godi...@sugarlabs.org> > wrote: > >> On Mon, Apr 20, 2015 at 7:28 PM, Sam P. <sam.parkins...@gmail.com> wrote: >> >>> Hi Gonzalo, >>> >>> On Tue, Apr 21, 2015 at 3:37 AM Gonzalo Odiard <godi...@sugarlabs.org> >>> wrote: >>> >>>> But if the server url can be configured (as in the proposal) >>>> In theory you could Sugar Network too at the server side, right? >>>> We only need define a standard way to provide context, like a parameter >>>> for the bundle_id >>>> >>> >>> Yes, that is possible. The api is very simple, the webview URL is set >>> to: >>> >>> SERVER/goto/BUNDLE >>> >>> >> Should be good check and agree with Sugar Network developers. >> Could be a good idea add the nick name and the user colors as >> parameters? >> > >> >> >>> So, you could make sugar network respond to this, add a redirect or >>> create a separate redirector server (as I do with >>> socialhelp.sugarlabs.org). >>> >>> It also has the merged native/web toolbar. The webview adds the class >>> "sugar" to your document body so you can then compensate for the 55x55 >>> close button on the top right. >>> >>> >> I would prefer use just the standard Sugar toolbar. >> If the page design change, or you use another server (like Suugar >> Network) or if you >> have a monitor with different pixel size, the merged toolbar will look >> wrong. >> > > I have to disagree with you here. > > For pixel size, websites just use em for the toolbar instead of px. Sites > like sugar-network seem to already be doing this. You must use em in order > to not look like tiny font on the xo anyway. > > For other services, it is super duper easy to integrate. For example, > this is all the CSS needed for discourse: > > .sugar header.d-header { > width: -webkit-calc(100% - 2.813em); > } > > Or for sugar-network: > > .sugar #toolbar { > width: -webkit-calc(100% - 2.813em); > } > > And even if the app does not have a toolbar, it is just a little button in > the top right and it looks fine. > > >> >> You lost 55 px, but you remove complexity and gain flexibility. >> > > 55px is very important. On some platforms, it is actually even 75 px. > > You loose 55px top padding, 55px bottom padding, 55px sugar toolbar and > then ~55px for the web toolbar. That brings the total to 220px or 300px on > a device with XO pixel density. What that equates to is very small. I had > a go on my XO [1], and there was only 7cm height left for the content > (almost same for discourse and sugar-network)! > > I understand that the XO is not our only platform. But on a small laptop, > adding more toolbars is just counterproductive. > > >> We can use the same viewhelp.py, just adding a toggle bottom to switch to >> the social help (at the left, the only buttons aligned at the right are >> the Stop buttons) >> > > > The idea of a toggle in the bottom left sounds good. > > Thanks, > Sam > > [1] http://imgur.com/FJFAcpl > > >> >> >>>> Regarding the proposal, I would like to see this more integrated with >>>> the Help view. >>>> Then the changes would be: >>>> * Don't show two entries in the menu, one for the local help and >>>> another for the social help. >>>> First, because in the cases where we have a help for the activity, is a >>>> good idea show >>>> that first, and add a button to go o the server if configured. >>>> * Right now, we show the Help menu only for activities with local Help >>>> available. >>>> We should show the menu always, and if not local help is available go >>>> to social page. >>>> >>> >>> Do you have a UI design in mind? >>> >>> Here is a quick mockup to start the conversation if you want: >>> http://people.sugarlabs.org/sam/mockup.png >>> >>> >> >>>> My main concern with this feature is how to solve the change to webkit2 >>>> without break >>>> all the webservices. I think we should include the main (and working) >>>> webservices in the sugar code, >>>> port them to webkit2, and then land this feature. >>>> >>> >>> That sounds like a good idea. >>> >>> If worst comes to worst, we could use webkit1. webkit2 has the new >>> shiny stuff and webkit1 is old, we will have to move someday and why not >>> before there are way too many web services! >>> >> >> Is good know we have that alternative if we can't land all before May 18. >> Maybe you can use webkit1 to land the feature and nake the change later. >> >> Gonzalo >> >> >>> >>> Thanks, >>> Sam >>> >>> >>>> >>>> Gonzalo >>>> >>>> >>>> On Mon, Apr 20, 2015 at 2:17 PM, Sebastian Silva < >>>> sebast...@fuentelibre.org> wrote: >>>> >>>>> Hi, >>>>> >>>>> For some reason this email found it's way into gmail's spam folder. >>>>> >>>>> However the topic is very important. >>>>> >>>>> I disagree that this implementation needs to be adopted. >>>>> In particular, most deployments still don't have a reliable connection >>>>> to the Internet and we don't want to introduce a dependency on it. Social >>>>> help might (and should) come from peers first. >>>>> >>>>> However, work has been ongoing from different deployments in this >>>>> (social) direction so it's generally accepted that Sugar needs it. Our own >>>>> work in Perú has been aligned with Alsroot's work on the Sugar Network ( >>>>> we >>>>> developed the first UI, here's a short video explaining it: >>>>> http://somosazucar.org/2012/06/04/un-avance-de-la-red-azucar-0-3-sneak-peek-of-sugar-network-0-3/ >>>>> ). >>>>> >>>>> This work is ongoing. It involves a very light local server capable of >>>>> synchronizing user resources asynchronously (including comments, bundles, >>>>> etc) *in both ways*. >>>>> >>>>> The effort is very much appreciated. I think we need to morph the >>>>> proposal into something that is generic or pluggable, and try to work with >>>>> Alsroot on this. >>>>> >>>>> Regards, >>>>> Sebastian >>>>> >>>>> >>>>> On 19/04/15 20:59, Sam P. wrote: >>>>> >>>>> Hi All, >>>>> >>>>> One feature I'm proposing for the 0.106 cycle is Social Help. Social >>>>> Help was previously proposed by Prasoon Shukla as a GSOC project, however >>>>> my proposal is slightly different. >>>>> >>>>> Patch Link: https://github.com/sugarlabs/sugar/pull/483/commits >>>>> Feature Page: http://wiki.sugarlabs.org/go/Features/Social_Help >>>>> YouTube Video Summary: https://youtu.be/_WzwVZ60Tbw >>>>> >>>>> I would like to invite discussion on the feature so we can land this >>>>> for 0.106. >>>>> >>>>> Thanks, >>>>> Sam >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sugar-devel mailing >>>>> listSugar-devel@lists.sugarlabs.orghttp://lists.sugarlabs.org/listinfo/sugar-devel >>>>> >>>>> >>>>> -- >>>>> I+D SomosAzucar.Org >>>>> "icarito" #somosazucar en Freenode IRC >>>>> "Nadie libera a nadie, nadie se libera solo. Los seres humanos se liberan >>>>> en comunión" - P. Freire >>>>> >>>>> >>>>> _______________________________________________ >>>>> Sugar-devel mailing list >>>>> Sugar-devel@lists.sugarlabs.org >>>>> http://lists.sugarlabs.org/listinfo/sugar-devel >>>>> >>>>> >>>> >>>> >>>> -- >>>> Gonzalo Odiard >>>> >>>> SugarLabs - Software for children learning >>>> >>> >> >> >> -- >> Gonzalo Odiard >> >> SugarLabs - Software for children learning >> > -- Gonzalo Odiard SugarLabs - Software for children learning
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel