When we started the work in web activities, we decided work with webkit2,
because is possible solve a few problems in the client side,
without need a local webserver.
But right now, in the XOs, we have F18 working, and Webkit2 crashes,
then I didn't find other solution than modify webactivity to w
I think it's good to have this upstream because otherwise changes to
sugar-web will easily break webkit1 support.
I'm not completely convinced we should support webkit1 yet. I'm worried it
will be pretty painful to maintain. It should be possible to port webkitgtk
2.2 to Fedora 18...
Though I sup
On Wed, Nov 27, 2013 at 1:04 PM, Daniel Narvaez wrote:
> I think it's good to have this upstream because otherwise changes to
> sugar-web will easily break webkit1 support.
>
> I'm not completely convinced we should support webkit1 yet. I'm worried it
> will be pretty painful to maintain. It shou
Nice!, I quickly looked at the patch and I urged try to encapsulate the all
logic of webkit2 and the webkit1 in separate modules, using a luck of
strategy pattern or do something polymorphic, but I notice that it is a
decision not yet taken (as Daniel says), I doubt whether to spend time on
this fo
I am not opposed to alternative implementations,
if we can "keep it simple".
This is a workaround for a problem, in the end, we want remove it,
when is not needed anymore.
Gonzalo
On Wed, Nov 27, 2013 at 2:22 PM, Rogelio Mita <
rogeliom...@activitycentral.com> wrote:
> Nice!, I quickly looked
I mean, because the goal is remove in the future, we need isolate this
logic in a separate module to make this transparency on webactivity
module, this is what I mean.
And the elimination process should be going to the main module
(webactivity) which is a kind of controller in this case and then re
On Wednesday, 27 November 2013, Gonzalo Odiard wrote:
>
> On Wed, Nov 27, 2013 at 1:04 PM, Daniel Narvaez
>
> > wrote:
>
>> I think it's good to have this upstream because otherwise changes to
>> sugar-web will easily break webkit1 support.
>>
>> I'm not completely convinced we should support we
I'm unconvinced that it will be a short term workaround. It will be hard to
get rid of.
We are implicitly adding support for webkit 1.8 (API 1) to sugar-web. We
might have to write sugar-web code which is webkit1 specific. People will
write activities which runs on 1.8. They will use non
forward-c
I'd really like to get feedback from more people about this!
Ccing sugar-web contributors.
On Wednesday, 27 November 2013, Gonzalo Odiard wrote:
> When we started the work in web activities, we decided work with webkit2,
> because is possible solve a few problems in the client side,
> without ne
I need more context about emergence of sugar-toolkit-gtk3 but...
I am agree with that points:
Gonzalo says:
> Another alternative is find what is crashing in webkit2 and solve it, but
> is out of my knowledge.
Always is an alternative write code for cover backward compatibility if
there are all
What do you mean with "emergence of sugar-toolkit-gtk3"?
On Tuesday, 3 December 2013, Rogelio Mita wrote:
> I need more context about emergence of sugar-toolkit-gtk3 but...
>
> I am agree with that points:
> Gonzalo says:
>
>> Another alternative is find what is crashing in webkit2 and solve it,
2013/12/3 Daniel Narvaez
> What do you mean with "emergence of sugar-toolkit-gtk3"?
I do not know the story of how this package came, when.., the main
purpose.., not that long ago I'm on this list
>
>
> On Tuesday, 3 December 2013, Rogelio Mita wrote:
>
>> I need more context about emergence
Hi Daniel,
May be I miss something but I don't see any compatibility risk on existing
Web Activity neither need to upgrade the Sugar Web Framework. Right ?
Another point to be sure to understand: does the change to webkit1 mean a
change of the HTML rendering engine and so a risk regarding HTML5
co
Hi,
2013/12/2 Daniel Narvaez :
> I'd really like to get feedback from more people about this!
>
> Ccing sugar-web contributors.
I think we should develop sugar-web looking at the future, which in
the case of GTK is WebKitGTK2.
That being said, I don't mind a fallback to WebKitGTK1 if WebKitGTK2
I've not said nothing yet because I'm not sure what to say.
Certainly, I don't like the idea of having two versions of webkit, but I
understand that this would be a temporal workaround.
Daniel said:
> I'm unconvinced that it will be a short term workaround. It will be hard
> to get rid of.
+1
I
On 3 December 2013 13:51, Rogelio Mita wrote:
>
>
> 2013/12/3 Daniel Narvaez
>
>> What do you mean with "emergence of sugar-toolkit-gtk3"?
>
>
> I do not know the story of how this package came, when.., the main
> purpose.., not that long ago I'm on this list
>
It's the python library you use to
On 3 December 2013 15:54, Lionel Laské wrote:
> Hi Daniel,
>
> May be I miss something but I don't see any compatibility risk on existing
> Web Activity neither need to upgrade the Sugar Web Framework. Right ?
>
No issue with the current Web activity.
Currently sugar-web doesn't need any change
On 3 December 2013 20:08, Manuel Quiñones wrote:
> I think we should develop sugar-web looking at the future, which in
> the case of GTK is WebKitGTK2.
>
> That being said, I don't mind a fallback to WebKitGTK1 if WebKitGTK2
> is not available in the toolkit. But I think that we should not make
On Wed, Dec 4, 2013 at 3:26 PM, Daniel Narvaez wrote:
> On 3 December 2013 20:08, Manuel Quiñones wrote:
>
>> I think we should develop sugar-web looking at the future, which in
>> the case of GTK is WebKitGTK2.
>>
>> That being said, I don't mind a fallback to WebKitGTK1 if WebKitGTK2
>> is not
2013/12/4 Gonzalo Odiard
> * If there are a way to implement a feature compatible with webkit1 and
> webkit2,
> with a comparable complexity, is encouraged use it.
>
About that:
using a web-server for both webkit1 and webkit2 is feasible?
over the course of thread I read that was a decision to a
On 4 December 2013 19:40, Gonzalo Odiard wrote:
>
>
>
>
> Just to clarify, the spirit of this last line is:
>
> * Do not allow special casing of sugar-web to support _only_ webkit1.
>
> ?
>
Do not add code which is necessary for webkit1 support only. For example,
do not have two separated getEnv
On 4 December 2013 19:50, Rogelio Mita wrote:
>
> 2013/12/4 Gonzalo Odiard
>
>> * If there are a way to implement a feature compatible with webkit1 and
>> webkit2,
>> with a comparable complexity, is encouraged use it.
>>
>
> About that:
> using a web-server for both webkit1 and webkit2 is feasib
2013/12/4 Daniel Narvaez
> This is a good concrete example of what worries me. Assuming the custom
> protocol is a slightly better solution (it might not be, it's a bit hard to
> evaluate but... for the sake of this dicussion let's assume it is), what do
> we do?
*I think in a loud voice and I
On 4 December 2013 20:06, Rogelio Mita wrote:
>
> 2013/12/4 Daniel Narvaez
>
>> This is a good concrete example of what worries me. Assuming the custom
>> protocol is a slightly better solution (it might not be, it's a bit hard to
>> evaluate but... for the sake of this dicussion let's assume it
2013/12/4 Daniel Narvaez
> I see your point of course. Though if we can keep the webkit2
> implementation the best it can be and, at the same time, allow people like
> Gonzalo to provide rudimentary support for web activities in deployed/ing
> software, maybe it's a good compromise... (Thinking o
2013/12/4 Daniel Narvaez :
> On 3 December 2013 20:08, Manuel Quiñones wrote:
>>
>> I think we should develop sugar-web looking at the future, which in
>> the case of GTK is WebKitGTK2.
>>
>> That being said, I don't mind a fallback to WebKitGTK1 if WebKitGTK2
>> is not available in the toolkit.
26 matches
Mail list logo
