Re: [Sugar-devel] [DESIGN] Browse PDF handling
Hi Daniel, On 15 Feb 2012, at 22:29, Daniel Drake d...@laptop.org wrote: 2012/2/2 Manuel Quiñones ma...@laptop.org: I'm proposing, for the new and fresh Browse wearing WebKit, the following behaviour when clicking on a link to a PDF: - the PDF is shown in a new tab, next to the current - basic document navigation is provided to the user - as well, a button to save to Journal is provided Using the save to Journal button, the kid can now read the PDF starting the full-featured Read activity. This behaviour is similar to what Safari does, and I think it fits Sugar user interface better than other approaches we where thinking before, like start Read directly, which provokes an interruptive activity switch. Also this way, an entry in the Journal is made only if the user ask for it, and allows a quick read of the PDF then you can decide on storing. I don't think this is the right direction, personally. I agree that right now it is a horrible user experience to open a PDF file from Browse, but this is something that we should fix at the Sugar/Journal level. From a technical or design standpoint I don't see what's stopping us in making a click on a PDF download link in Browse immediately open Read, solving the interruption described above. FWIW, even with the latest XO hardware Read takes about 15sec to launch (and then more to load/display the pdf). This would make for a rather jarring experience, along with jumping you out of the browse UI. Casually hitting pdf content while web browsing, perhaps not even realising the next link is to pdf content, seems to be a separate workflow/use-case than using a dedicated reader (annotations, bookmarks, resuming at the page last viewed). The storage aspect is a little more interesting, but doesn't really follow the rest of Sugar where the Journal records what the user has done without considering otherwise. Your proposal seems to be basically bundling Read into Browse, and this will result in the usual side effects of code duplication: having to fix bugs and add new features in 2 places, Yes, agreed this is the cost if we want to smooth the workflow when web browsing pdfs. Regards, --Gary confusing the user by having 2 ways to do the same thing, providing a strange user experience of switching from one to the other, using more system resources than otherwise, etc. And as soon as another file format gets popular on the web we'd be pushed to roll another activity into Browse as well. Either way, I definitely applaud the effort to make the textbook experience better in sugar, many thanks for spending time on this. cheers Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Mystery reboots
Today at 10:57 EST and 11:01, our only remaining kvm host housetree rebooted for no apparent reason, causing a short outage of several services. We are currently investigating the cause. Houstree had over 300 days of uptime, but since as of this week the load is considerably higher due to the VMs we moved from Treehouse. -- Bernie Innocenti Sugar Labs Infrastructure Team http://wiki.sugarlabs.org/go/Infrastructure_Team ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Graficador Lybniz-1
Activity Homepage: http://activities.sugarlabs.org/addon/4539 Sugar Platform: 0.82 - 0.96 Download Now: http://activities.sugarlabs.org/downloads/file/27864/lybniz_graph_plotter-1.xo Release notes: Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fedora Sugar Test Day - Test case content, location
On March 22 there will be a Sugar test day for Fedora 17. This means that the Fedora community in general will be gathering to look at Sugar and see what issues we have close to the end of the Sugar 0.96 cycle. To help keep track of what was found and tell people where to look, we ideally should have test cases for the volunteers willing to help us that day that may be unfamiliar with Sugar. But the first question I have is where these test cases should be hosted. Historically OLPC has tried to use their wiki with some semantic markup to store test cases results for both the XO and Sugar. But this setup is not easily searched, is prone to caching old information unless the Wiki pages are purged, and can get confusing if you have to support later test plans and/or updated test case versions. Fedora also stores test cases in their Wiki, and links them to packages in Bodhi to help in verification. They take a simpler approach to their Wiki design than what OLPC uses. Fedora supposedly was to move to a test case management system called Nitrate to match Red Hat, but to date this has not happened. A year or so ago I had a wild idea to create a system where test cases and results could be exchanged so Ubuntu users could see how a program worked in Fedora, what upstream saw, etc. But this has yet to materialize beyond a few sketches. So we need to come up with a location design that has a set of test cases results that everyone (including Ubuntu, etc.) can consider authoritative up-to-date for testing Sugar, and ideally support test cases for XO hardware, the school server, etc. as well. --- SJG ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Testing] Fedora Sugar Test Day - Test case content, location
The issue of using a dedicated software product to track test cases
results has come up from time to time.
The situation as I understand it is that OLPC in general prefers to use the
resources of other {often upstream} partners whenever possible. It is felt
by some people that we would spend more time maintaining our own system in
this case than we would save by having it.
So I am waiting for Fedora to implement Nitrate hopefully support us as a
product-of-sorts, presuming that does eventually happen. I'm also
half-waiting to see what they come up with for automated testing so that
Sugar UI work goes a similar route, even though implementing something now
could potentially save me hours of testing time.
There also is a desire with both OLPC and Fedora to support anonymous users
with their testing systems, and not all test case management software out
there supports that.
On Thu, Feb 16, 2012 at 2:52 PM, Kurt H Maier karmaf...@gmail.com wrote:
Would it be appropriate to investigate something like FitNesse[1] or
testmaster[2] for Sugar and/or OLPC? Software like this might be
overkill, but on the other hand, it would be nice to have a single
point to collect testing standards results, and be able to store
testing history in a queryable format. Testmaster in particular is
pretty easy to use and doesn't require much in the way of hosting;
it's just CGI.
[1] http://fitnesse.org/FitNesse.UserGuide.OneMinuteDescription
[2] http://testmaster.sourceforge.net/
--
# Kurt H Maier
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
Daniel Drake dsd at laptop.org writes: There have been various discussions in the past suggesting a move from mozilla to webkit for the Browse activity and related components, but I've never really been convinced: there is always a cost to switching, and convincing-looking numbers from webkit supporters tended to be countered with convincing-looking numbers from mozilla supporters. daniel, hi, it's just been brought to my attention just how fed up the mozilla foundation's codebase has become. i'm the lead developer of pyjamas, and have been tracking the situation as it goes from bad to worse to just completely f*g useless for quite some time. as of xulrunner-1.9.1, there was one outstanding bug which, if it had been fixed as described in the bugreport just below, would have made the use of hulahop absolutely perfect for pyjamas-desktop... ok, not absolutely perfect, but passably so. https://bugzilla.mozilla.org/show_bug.cgi?id=502234 as you can see, a decision was made to go with a solution which made the code _worse_ to work with. a band-aid, made out of ignorance rather than intelligent evaluation and decision-making, that actually broke python-xpcom. there appears to be within the mozilla foundation an insanity that says we are gods, javascript is our lord and saviour, any other programming language or the use of any other programming language can go take a running jump. i'm further deeply disappointed and angered to hear that you have found evidence that embedding of the gecko / xulrunner engine is _also_ prevented, prohibited and actively discouraged. it begs the question, what the bloody hell are the mozilla foundation playing at?? anyway - leaving that aside, i thought you should know that yes there is an alternative option in the form of webkit, but that it is equally fraught. all in all i think that the free software community is completely and utterly failing to get with the picture with respect to browser engine technology, and that it is pretty ironic that MSHTML (microsoft's web browser engine technology) just works out-of-the-box and yet the U.S. Dept of Justice and the E.U. Monopolies and Mergers Commission tried to force microsoft *not* to have MSHTML pre-installed. anyway - end that, allow me to outline what's possible with what's already out there. === WebKit === What I'd like to do now is spec out a project for someone to take on, moving Browse to WebKit in a way that can be clearly justified for the community. But, WebKit is totally new to me so I have many open questions. Can anyone help me answer them? I'll be collecting the results into a wiki page (to form the above spec). 1. I've only made half the argument above. Mozilla is bad, but why is WebKit the solution? The key questions here are: is it embeddable? yes. Does it work well when embedded? Do the developers support it being embedded? no they do not. mark rowe applied evasive dictatorship - bullying and technical goal-post moving that was shown later to be thoroughly hypocritical, allowing identical code which he earlier rejected with unreasonable arguments failing completely to even read counter-arguments or explanations as to why particular decisions had been taken. if you have the time, you can see evidence of his shockingly-bad behaviour here: http://bugs.webkit.org/show_bug.cgi?id=16401 the outcome of what he did has had severe knock-on ramifications as the webkitgtk code which is now in the webkit main tree has severe technical flaws that i am banned i.e. actively prevented and prohibited from discussing, outlining and helping with, on both bugs.webkit.org and also the webkit-dev mailing list. i have been posting various descriptions to help give hints to help fix some of these issues under accounts named webkit censorship bypass but the level of technical expertise is sufficiently high in order to fix these issues that they are dismissed as ramblings and are completely ignored. the consequences are that there are fundamental flaws in both webkitgtk and pywebkitgtk which cannot be fixed without some serious redesign work that will take the inexperienced webkitgtk developers several weeks to understand, and several weeks to implement. Does anyone have experience here? yes. The name WebKit makes it sound nice and modular, and the fact that WebKit itself isn't a browser would seem to support these arguments, but it would be nice being able to argue this on a more solid basis. ok. it's good... but... the code has been developed piece-meal. the mainline webkit tree has gobject bindings support, through which you can use gobject introspection to have python bindings on top of that... ... but the gobject bindings themselves (which are to the DOM) are... well, they're shit basically. and i can say that, because i wrote them. they were the first version, and you know what first version code is like. it's where you learn how to do
Re: [Sugar-devel] Browse and the move to WebKit
Marco Pesenti Gritti marco at marcopg.org writes: On 21 June 2011 23:23, Daniel Drake dsd at laptop.org wrote: You could have been even more convincing if you had used this API: http://webkitgtk.org/reference/index.html (yes, its webkit1, but it looks excellent from a GTK perspective, and a breath of fresh air after seeing what mozilla put you through with hulahop etc!) The reason I posted an example of the cross platform API is that I think it's what really set it apart from gtkmozembed. We would be using (directly or indirectly) the same API everyone else is using which means 1 it will be complete, 2 it will be stable, 3 it will be maintained by the core webkit developers. a word of caution: the core webkit developers do not like to receive input from free software developers: you are entirely at their mercy. they seek to gain complete control over the codebase. if your code does not fit with what they have dictated it shall do, your project is in jeapordy if you become dependent on them. this may sound really... bizarre, but it is direct experience. i worked extremely hard to create the webkit gobject bindings (which you have been discussing and i see using) and mark rowe worked extremely hard to destroy the efforts to make them available in a useful and useable form. unfortunately, mark rowe's efforts succeeded, and the free software community has lost the benefit of my experience and efforts to bring you useful and useable gobject bindings, for which i deeply apologise. it will be years before the damage done by mark rowe is fully comprehended. So, let me see if my understanding lines up with yours. WebKit2 provides an API specification, and all of the different frontends (Qt/GTK/...) implement that API, with only the minor tweaks needed to make it fit in to the platform? Yes. In your example, WKViewCreate() must have been provided as a GTK-specific thing, as it returns a GtkWidget. And the other platforms would provide their own platform-specific implementation? Yes. If I understand it correctly, the webkitgtk developers are aiming to provide both options. First, the cross-platform API implemented to return a GTK+ widget (looks like they've made great progress there). Secondly, a refresh of the GObject-style API, implemented based on top of that cross-platform API. This is what seems to be suggested here: http://blog.kov.eti.br/?p=110 Do you agree with that interpretation? That's also my understanding. As you suggest I do plan to get closer to the upstream development to really get a grip on this, but firstly, I'd be interested in your opinion on 2 further points: 1. If my understanding above is correct, do you think Browse should go with the cross-platform API, or the upcoming GObject-style one? I went back and forward on this. I was annoyed about introducing an extra layer (compared to direct python bindings of the cross-platform API), since there is already plenty of them in that stack. Though I think I'm now pretty convinced using the GObject API is the best approach for Sugar. It's more practical because there are people working on GObject but not direct python bindings. that's incorrect. i wrote the direct python bindings over a year ago: http://www.gnu.org/software/pythonwebkit the gobject bindings approach is fundamentally flawed and unfortunately you will not find this out until you begin to try *significant* usage of the DOM. the number of _actual_ projects that make significant usage of python DOM bindings to webkit, in the world, is a total of one (1) application: pyjamas-desktop. even in the microsoft world, the total number of actual projects that actually make comprehensive (100%) use of python COM bindings to MSHTML (Trident) is one (1) - pyjamas-desktop. i spoke to eric of the microsoft IE team about 2 years ago and he expressed surprise at what had been done, and confirmed that never, in his entire career working with IE, had anything quite so comprehensive as pyjamas-desktop ever been done. and it's necessary! you simply cannot have javascript-equivalent python bindings to the DOM that are not fully without fail absolutely cast-iron guaranteed without one single exception absolutely and 100% identical _to_ the javascript bindings. this was where the shit hit the fan when creating the gobject bindings to webkit, because mark rowe decided SIEG HEIL! I AM GOD! YOU WILL OBEY MY WHIM AND I HAVE DICTATED THAT YOU ARE AN IGNORAMUS WHO NEEDS TO BE TAUGHT A LESSON and unfortunately every free software project that tries to use the gtk gobject bindings will encounter serious fundamental problems as a result of his bullying. More flexible because you could use it from any language with gobject-introspection bindings. More consistent with the rest of the stack. really - don't do it. see the message earlier. i'm sorry i didn't
[Sugar-devel] [ASLO] Release Turtle Blocks-136
Activity Homepage: http://activities.sugarlabs.org/addon/4027 Sugar Platform: 0.82 - 0.94 Download Now: http://activities.sugarlabs.org/downloads/file/27865/turtle_art-136.xo Release notes: 136 ENHANCEMENTS: * Add method to retrieve plugin instance (Alan Jhonn Aguiar Schwyn) * New translations BUG FIXES: * Fixed regression in resistance sensor calibration for XO 1.75 * Fixed another problem with expanded compare blocks * Fixed problem with disappearing blocks due to dragging over hidden palettes 135 ENHANCEMENTS: * Changed mechanism for handling hidden blocks (used by some plugins) BUG FIX: * Restore currently selected palette after hide/show palette cycle Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release I Can Read-3
Activity Homepage: http://activities.sugarlabs.org/addon/4529 Sugar Platform: 0.82 - 0.94 Download Now: http://activities.sugarlabs.org/downloads/file/27866/i_can_read-3.xo Release notes: 3 ENHANCEMENT: * Show words in uppercase as well as lowercase 2 BUG FIXED: * new recording for jirafe Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Pippy-45
Activity Homepage: http://activities.sugarlabs.org/addon/4041 Sugar Platform: 0.82 - 0.96 Download Now: http://activities.sugarlabs.org/downloads/file/27867/pippy-45.xo Release notes: *New translations. *Not harcoding tamtam-edit path (using get_bundle_path) fixes SL#2829. == Souces == http://download.sugarlabs.org/sources/sucrose/fructose/Pippy/Pippy-45.tar.bz2 Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
https://bugzilla.mozilla.org/show_bug.cgi?id=728055 success! http://lkcl.net/hulahop/ ok, for a given definition of success :) i had to comment out the js_push_context and js_pop_context (could not be arsed to deal with those) - you might find that you have to put in some #includes for spidermonkey, and if you ask nicely on this bugreport you may get an answer: https://bugzilla.mozilla.org/show_bug.cgi?id=728115 please can i advise you to get onto that bugreport (728055) and say thank you to josh matthews for kindly pointing out the existence of XRE_InitEmbedding2? other changes i made include: * removing calls to set up NS_XPCOM_COMPONENT_REGISTRY * changing #include and reference to nsIDOMWindow2 to just nsIDOMWindow * commenting out the javascript push and pop. other than that, it works! amazing. and this is with the standard debian packaging for xulrunner-9.0-dev out of debian/testing as of yesterday. yes, that _includes_ python-xpcom (aka pyxpcom). now. can i strongly STRONGLY recommend that you cease the use of webkit and return to using hulahop? you are entirely free to completely ignore this advice, and to see how far it gets you to be using webkit with gobject introspection. actually, in some ways it would be incredibly useful an exercise because you will then have a clear idea of the serious and fundamental flaws that are inherent in webkit's gobject bindings. i will be more than happy to help accelerate the OLPC projects' understanding of the situation, as long as you agree to release a public and detailed technical description of the issues encountered onto the webkit-dev mailing list. preferably without mentioning where you got the advice from, because the webkit developers will treat you like shit if you even mention my name. l. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse and the move to WebKit
better news: i've just confirmed that: a) the removal of js_push_context and pop context was a spurious error, those functions are now restored, confirmed as compiling and existing (untested) b) the usual critical pyjamas-desktop tests, Helloworld, JSONRPCExample, KitchenSink and Mail all have the exact same behaviour as they used to, way back before the xpcom API breakage [where we all had to wait for todd whiteman to update pyxpcom] this is really really good news because it means that the people who have been keeping an eye on the debian packaging of hulahop and have been going arse! it's fecked! quite a lot will now be happy that it all works, and i am confident that within a few weeks/months people will be able to do apt-get install pyjamas-desktop python-hulahop again and have it all work. yeAHHH! :) l. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
