Re: chrome vs firefox: on mouse leave/enter event
On Feb 14, 9:58 am, Thomas Broyer wrote:
> I don't have time to try it out with GWT, sorry, but just to add some input
> to the possible issue: mouseover and mouseout events bubble, so if your
> mouse enters a child element of the B widget's root element, the event will
> bubble up to B's root element. GWT filters those events out in
> Widget#onBrowserEvent's default implementation to somehow mimic IE's (and
> now HTML5's / DOM3 Events') mouseenter and mouseleave
> events:http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/...
thomas, hi, thanks for pointing this out. what we had was using
DOM.eventGetFromElement for mouseover, whereas the code in GWT uses
eventGetToElement.
i've modified the equivalent pyjamas code to this:
elif etype == "mouseover":
to_element = DOM.eventGetToElement(event)
if to_element and not DOM.isOrHasChild(sender.getElement(),
to_element):
for listener in listeners:
listener.onMouseEnter(sender)
return True
elif etype == "mouseout":
to_element = DOM.eventGetToElement(event)
if to_element and not DOM.isOrHasChild(sender.getElement(),
to_element):
for listener in listeners:
listener.onMouseLeave(sender)
return True
return False
where it is this in java:
public void onBrowserEvent(Event event) {
switch (DOM.eventGetType(event)) {
case Event.ONMOUSEOVER:
// Only fire the mouse over event if it's coming from outside
this
// widget.
case Event.ONMOUSEOUT:
// Only fire the mouse out event if it's leaving this
// widget.
Element related = event.getRelatedEventTarget().cast();
if (related != null && getElement().isOrHasChild(related)) {
return;
}
break;
}
DomEvent.fireNativeEvent(event, this, this.getElement());
}
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: TreeItem child widgets do not have onAttach called
On Aug 11, 12:34 am, Jim Douglas wrote: > Have you considered using this version of TreeItem, which takes a > Widget? > > http://google-web-toolkit.googlecode.com/svn/javadoc/2.3/com/google/g...) > http://google-web-toolkit.googlecode.com/svn/javadoc/2.3/com/google/g...) okay. right. i didn't notice the 2nd link was to TreeItem.setWidget (groups.google.com hid the text *sigh*). that calls tree.adopt. i just went through the code, down to Tree.java. Tree.adopt calls setWidget (the base version). setWidget then calls onAttach. soo... actually... yeah, that might do the trick. it's... klunky (as in, it's non-standard behaviour) and thus is going to catch users out. i.e. if you _don't_ call that setWidget function, you're stuffed. let me investigate further ok? l. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: TreeItem child widgets do not have onAttach called
On Aug 11, 12:34 am, Jim Douglas wrote: > Have you considered using this version of TreeItem, which takes a > Widget? > > http://google-web-toolkit.googlecode.com/svn/javadoc/2.3/com/google/g...)http://google-web-toolkit.googlecode.com/svn/javadoc/2.3/com/google/g...) that's the exact [equivalent] class being used, and it's the exact same class [equivalent] that we've made a 6-line patch to, in order to fix the bug that has been found [in the exact corresponding equivalent pyjamas codebase, pyjamas/library/gwt/ui/TreeItem.py]. > The TreeItem isn't itself a Widget, but it can contain a Widget, and > that contained Widget (think of it as a tree item renderer) can manage > its own events. that's the point, jim: it *doesn't* manage its own events, because onAttach is never called on the widgets that are added to the TreeItem. thus, anything that's added to TreeItem is completely isolated, as far as events are concerned. no onClick, no onDoubleClick, no onMouseMove, no onMouseUp - nothing. i apologise - i realise that it's quite difficult to appreciate that the pyjamas codebase is the same - functionally - as GWT, to the point where it's possible to refer developers to the GWT online documentation rather than have to write our own. it's virtually identical to that of GWT, so much so that we can actually use language translator tools (automatic and semi-automatic) to port GWT java to pyjamas python. but, yes, you've correctly identified the gwt UI class that will have the exact same bug that was discovered by a pyjamas user. and, therefore, _because_ the code is effectively identical, there is the exact same bug in GWT. what the user did was to take the code for onAttach and onDetach in pyjamas/library/gwt/ui/Panel.py and cut/paste it into TreeItem.py. thus, correspondingly, to fix this bug in GWT, you (GWT developers) need to take the exact same code that is in the gwt/ui/Panel.java "onAttach" and "onDetach" functions, cut/paste it into gwt/ui/ TreeItem.java and the bug is fixed. @begin namespace GWT's client/ui widgets on all widgets below but first, you need to realise that there _is_ a bug :) for that, you'll need to look at the example test-case provided by the pyjamas user, and port it to GWT. it's actually very simple: add a CheckBox to a TreeItem; add the TreeItem to a Tree; add the Tree to a RootPanel. add a click handler to the CheckBox, which prints "hello world" or something. @end namespace click on the checkbox. you'll find that absolutely *nothing* happens. that's the bug. does that make sense? l. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: TreeItem child widgets do not have onAttach called
On Aug 4, 5:36 pm, Jim Douglas wrote: > The basic issue here is that TreeItems aren't Widgets, so (by design) > they don't handle their own events. yeeesss... but that doesn't mean that child widgets of TreeItems should be completely terminated from any possibility of having *their* events handled, does it. > You'll want to review Tree to > decide how best to manage your events. no, we won't [want to review Tree to decide how to best manage events]. allow me to illustrate. what you're saying is that, instead of adding about 6 lines of code (an implementation of onAttach and onDetach which does exactly what Panel does - calls the onAttach and onDetach of all child widgets, so that they get joined into the event handling infrastructure), you're expecting developers to do this: * sub-class Tree and/or hook into Event Preview or onBrowserEvent * receive *all* events in Tree not just one or two, because you cannot predict what events the child widgets will want. or, you have to add duplicated infrastructure to receive and manage events that somehow magically notify the containing Tree that actually, guys, you wanted the event callback to be here but really it's gonna be down here in this random Tree object which you should really have f***-all knowledge of, it's miles down the hierarchy * do a massive recursive node-walk of all TreeItem no wait all TreeItem _child_ objects, including *recursively* walking the child objects of the TreeItem child objects in order to identify the GWT (or in this case pyjamas) object that is associated with the DOM element that received the event * add in infrastructure which duplicates existing code which is part of the tried-and-tested GWT (or in this case pyjamas) codebase, hooking *back* into the standard event handling system further up into the child hierarchy. * using that duplicated code, as the correct object has been identified (through the highly computationally expensive step 3 above), call the relevant event callback. now, when it's put like that - which is what you're asking developers to do - it does sound a bit like you're completely off your head, please excuse me for pointing that out. 6 lines of code vs 400+ lines of code and a massive runtime performance hit, duplicating functions that are built-in to web browsers anyway _and_ duplicating functionality which already exists in GWT (and pyjamas), there's no real comparison, is there? so - i invite you to look at this again, *without* the "static mindset" of "TreeItems aren't Widgets" [implication being, there's no way that the code can be either changed or fixed, and no improvements will ever be made to it]. regarding "it's by design" - designs should only remain static if they actually serve the purpose for which they were designed. in this case, we have an actual real-world use case which demonstrates that the design is, 'scuse me for saying it, shit. or, perhaps, i invite you to consider describing what possible implications there could be to TreeItem having an onAttach and onDetach. you'll find that even UIObject has onAttach and onDetach (as stubs), so it's not like it's not possible to do this. the real question is: does adding onAttach or onDetach have any unintended consequences / side-effects that need a workaround? for example, what happens to up-down-left-right-enter key navigation, is that affected? l. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: TreeItem child widgets do not have onAttach called
okaay... rright: the message took its sweet time to appear here in the forum, and so i couldn't cross-reference the forum with the bugreport until that had happened, duh, so now that's happened, here's the reference: http://code.google.com/p/google-web-toolkit/issues/detail?id=6656 -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
TreeItem child widgets do not have onAttach called
folks hi, this is luke, the lead developer of the python port of GWT. we regularly track the GWT source code, to the point of having 3 different semi-automated java-to-python converters of varying levels of sophistication, and the reason for doing that is to save vast amounts of time and resources, because the GWT source code is much more tested. _very_ occasionally we find a bug in GWT which has been transferred - verbatim - from the direct translation to python. it would be very good, therefore, to have peoples' input on this issue, and to have a discussion of this bug which could affect users of both GWT and pyjamas. the issue is this: a user has created a Tree and has placed TreeItems in it, and then attached a CheckBox onto the TreeItem. the problem is that in these CheckBoxes, no onClicks or any other kind of event handling occur, period. now, i'm dead impressed that this new pyjamas developer then went and delved into the pyjs ui source code and found the problem _and_ created a fix: http://code.google.com/p/pyjamas/issues/?id=638 diff --git a/library/gwt/ui/TreeItem.py b/library/gwt/ui/TreeItem.py index f5c0489..d5a413f 100644 --- a/library/gwt/ui/TreeItem.py +++ b/library/gwt/ui/TreeItem.py @@ -127,10 +127,18 @@ class TreeItem(UIObject): return item def onAttach(self): -pass +for item in self.children: +item.onAttach() +w = self.getWidget() +if w: + w.onAttach() def onDetach(self): -pass +for item in self.children: +item.onDetach() +w = self.getWidget() +if w: + w.onDetach() def getChild(self, index): if (index < 0) or (index >= len(self.children)): so, the question that i have is very simple: is this the right thing to do? remember that, as we didn't design the GWT UI widget infrastructure (merely "port" it pretty much verbatim to python), analysing the implications of issues such as this is somewhat outside of our... scope / resources / time / "community abilities" shall we say. plus, i believe it's important to raise this with the GWT community not least because someone else in the GWT community may wish to do exactly the same thing: have TreeItems where the widgets within them bloody well work! :) i'd be interested to hear the thoughts of the GWT community on this issue. fyi read-only archive of pyjamas-dev exact same topic is here: http://groups.google.com/group/pyjamas-dev/browse_thread/thread/b69ad20a6af2085e l. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
possibly obscure bug present in DialogBox and all other capture-related widgets
this is a courtesy message to inform the GWT team of a potential issue that you might like to investigate: http://code.google.com/p/google-web-toolkit/issues/detail?id=5167 i've been tracking this issue in pyjamas for two years, and, last time i checked the GWT KitchenSink showcase and gwt-dnd the issue was reproducible there. l. -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-tool...@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
django forms - JSONRPC API - progress
the basic plan is to provide a generic JSONRPC front-end to Django forms which could conceivably become a de-facto interoperability standard for web 2.0 applications to create, validate and store data in "forms". i've just added "describe" and "describe_errors". http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/pyjs/jsonrpc/django/jsonrpc.py?view=markup the basic idea, as mentioned previously, is to allow an AJAX application, using JSONRPC, to interact fully with Django Forms. i.e. *without* forcing the server to generate some dumb bit of HTML which you are forced to use, forced to perform HTTP POSTs on etc. etc. now that "describe" has been added, the next step will be to create an http://pyjs.org AJAX form "widget" that uses the "describe" command to find out what fields to build into the form. * CharField, FloatField, DecimalField etc. will result in a pyjamas TextBox, with the option for a TextArea being a user-defined option. * DateField, TimeField etc. will result in a calendar widget popping up, there's one i've found at: http://pyjamas-utils.googlecode.com/svn/trunk/examples/calendar/index.py * FilePathField will be interesting because it implies a level of interaction with the server: the most sensible widget to use here would be a recursive / interactive Tree Widget that performs further JSONRPC function calls to obtain subdirectory contents, on request. exactly what these fields will go in to, and what CSS style names will be attached to them, will be entirely up to the user, with sensible defaults provided. a Grid seems the most sensible, with the names on the left, and fields on the right, springs to mind, resulting in the construction of something similar to the "as_table" method of Django Forms. except pure AJAX. no HTML in sight. interestingly, i can't find anything in Django Forms which tells you how to specify "password" input boxes. also, RegexField's design destroys the possibility for finding out what the regex is (in string form), thus making it very difficult to perform client-side validation (using the ECMAScript Regex object). so there are a few hurdles yet to be overcome. the above can also be implemented in GWT, using exactly the same JSONRPC service, which is why i describe the API as being a de-facto standard. in fact, if you were feeling particularly masochistic (i.e. a PHP programmer) you could implement this in PHP, both client or server. anyone who would like to collaborate or contribute please do join the pyjamas-dev list. l. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
pyjamas "dynamic module" loading - something for GWT to adopt
as part of a reorganisation of the python port of GWT, pyjamas, i just
added dynamic module loading, using AJAX. i note that this is
something that has been on the GWT roadmap for quite some time. so,
having managed to implement it successfully in pyjamas i thought that
the GWT development team might like to know how it was done.
the deployment of dynamic module loading results in over a 60%
reduction in the amount of javascript cache file sizes, as the modules
can be shared across multiple platforms (GAE pyjamas users are hitting
the app engine limit even with the simplest of apps, due to the old
one-cache-file-per-platform design)
starting at the "bottom" of the tree of functionality:
pyjs_load_script, line 143:
http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/library/dynamicajax.js?revision=331&view=markup
this is an implementation of "the" standard method for adding
javascript, dynamically, to a web page. it creates a < script > node,
adds a src attribute and appends it to the DOM model. the result is
that at some point in the future, the browser notices, loads the
script, and executes it.
i say "executes" - this is where trouble typically occurs, due to over-
zealous garbage collection by browsers, with the result that the
output from pyjamas had to undergo a total reorganisation.
pyjamas output used to be entirely global in scope. module_class.
module_class_function. module_globalvariable. what browsers do is
that after a dynamically loaded script is run, any functions or
variables that have not been "attached" to anything in the _global_
scope (the main scripts), they are automatically and instantly garbage-
collected. so, instead of this:
pyjslib_Dict = function() {
}
pyjslib_Dict_init = function() {
pyjslib_Dict.prototype.__init__ = function() { ...
initialise ... }
}
the compiler output had to be _completely_ reorganised to this:
pyjslib = function () {
pyjslib.Dict = function() {
}
pyjslib.Dict.init = function() {
pyjslib.Dict.prototype.__init__ = function() { ...
initialise ... }
}
}
followed by, at the _bottom_ of the module, from the compiled output:
global_module_cache['pyjslib'] = pyjslib();
in this way, every single module has at least one ref-count in the
browser execution engine, and, given that absolutely _everything_ is
inside the "modulename = function { . }", the module doesn't get
garbage-collected and deleted.
looking at e.g. the design of dojo and the design of extjs, this is
pretty much what they do anyway (i haven't looked at output from GWT
because i don't do java development).
the second gotcha was this: dynamic loading of modules is
asynchronous, yet they are typically imported - especially in a
dynamic language such as python - synchronously. the mechanism for
dealing with this is in place, with a current assumption that it's ok
to load everything all at once, thanks to being able to take note in
the compiler of the complete list of all modules.
the key function which kicks off the initial importing, and makes a
note of the fact, is import_module(), line 22:
http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/library/pyjslib.py?revision=331&view=markup
this function can operate in both "static" mode - i.e. when the code
has been compiled entirely into one cache file - and also in "dynamic"
mode. also, each of the platform-specific cache files has a list of
"overrides" on a per-module basis, and in this way, in "dynamic" mode,
modules which are not platform-specific can be shared between
platforms, resulting in a dramatic drop in the amount of javascript
(something like a 60% reduction has been seen for the pyjamas
kitchensink example).
import_module works therefore in concert with the module "boilerplate"
template - see lines 12 and 18
http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/builder/boilerplate/mod.cache.html?revision=331&view=markup
and also with import_wait (see line 120 of pyjslib.py)
preload_app_modules in pyjslib.py is where the loop to wait for all
the modules to be imported is "kicked off" - but - note that
preload_app_modules takes a list of lists of modules! the reason for
this is to ensure that dependencies are respected.
the list of dependencies is created at compile time, using the pyjs
compile process itself to ascertain the list of imports that come from
the compilation of a module - line 333 and 371 of pyjs/build.py:
http://pyjamas.svn.sourceforge.net/viewvc/pyjamas/trunk/pyjs/build.py?revision=331&view=markup
note the use of the function "add_subdeps()". this function takes
pyjamas.ui.HTMLPanel and creates a list of dependencies:
['pyjamas', 'pyjamas.ui', 'pyjamas.ui.HTMLPanel']
it is _essential_ to create this list, and to add them to the
dependencies, so that the modules are dynamically loaded, and thus,
the global variables (pyjamas and pyjamas.ui) are created before
pyjamas.ui.HTMLPanel, for example.
so, to recap, here is what is done:
* the global modules is set to
Re: Suggestion: GWT port to Desktop
a simple example - i wrote an online games web site. there are four games written at the moment. backgammon, rummikub, poker and go. rummikub has 110 images loaded onto the page. firefox takes about 5-8 seconds to add all the tokens, one-by-one with javascript (compiled from python of course). pyjamas-desktop, using webkit, takes about 2 seconds. the javascript is gone in pyjamas-desktop; it's a glib / gobject binding direct to the c++ function which adds the image to the DOM model, direct. go has a whopping 725 images to be added to the page. firefox takes an incredible _thirty_ seconds to create this page on a 1.2ghz dual- core pentium laptop. pyjamas-desktop, using webkit, takes under ten. so even something as trivial as writing a simple entertainment application is pushing the limits of acceptable user tolerances. l. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: GWT port to Desktop
> When thinking of regular pages you might be right but I wasn't making > up the example. This was one of the reasons why we had to switch > from a browser-based application to a local running one. In this > specific case a tree showing all possible segments and fields > of an EDIFACT IFTMIN (one of the most complex structures of EDIFACT) > lead to waiting times of many seconds per mouse-click when working > with a browser on a modern PC. so, in this specific instance, being able to migrate - pretty much instantaneously and with zero code modifications from a [too-slow] browser-based environment to a [very-fast] desktop-based one would be a definite advantage, yes? especially given that 1) running compiled java instead of interpreted javascript would end up running much faster 2) webkit is _blindingly_ quick. that _would_ have saved your development team a great deal of time and money. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: GWT port to Desktop
On Oct 29, 9:44 am, rusty <[EMAIL PROTECTED]> wrote: > I'm partly humoured partly intrigued. How would this GWT have access > to the File System and other such resources, since by definition > javascript can't do any of that kind of thing. What if it wants to do > other cool things on your system? hi rusty, in this instance, what you do is you still keep even the _desktop_ version using JSONRPC or other XMLHTTPRequest derivative, and you use it to communicate on loopback with a "server" that is installed on your desktop machine. the fact that it's the same "server" that would be installed on a "web server" is irrelevant. in this way, you keep your application in an MVC framework. the "GWT" bits are the V. the "web server" bits - even when installed desktop- side - are the "MC" bits. and in the example you give, the "server" would perform accesses to the "File System", under the control of the separated-front-end GWT code. l. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: GWT port to Desktop
On Oct 28, 6:17 am, GWBasic <[EMAIL PROTECTED]> wrote: > The browser and desktop are fundamentally different environments, pyjamas-desktop shows that that's no longer really the case; it shows that there are sufficient concepts in the DOM model to map one-for-one into desktop widget set frameworks; it shows that, certainly when compared to Qt4 and GTK2, a DOM-model-based widget set is actually superior, offering better functionality, more functionality, and a simpler API! > really deliver is write once, test everywhere. If you want to have > some way of turning a GWT application into a desktop application; it > will probably exist at some point. yes. called GWT-Desktop :) > (Cough AIR Cough) that's a javascript-based route. and, ironically, AIR is based on webkit (just as pyjamas-desktop is based on webkit) > You will, > however, need to test your application on every operating system that > you plan on supporting; and potentially write special cases for > specific differences in each operating system that you support. why? why would that need to be the case? as Adobe AIR, google chrome, safari, iphone-safari and android shows, webkit is supported on _tons_ of platforms. by _staying away_ from desktop-specific APIs (and using XMLHTTPRequest to do communication, even on loopback 127.0.0.1) your entire app is OS-independent; the webkit-based runtime is OS- independent. as the GWT apps themselves show, it's not in the slightest bit necessary for the app to be OS-dependent, even when running in multiple different web browsers. l. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: GWT port to Desktop
On Oct 27, 3:54 pm, "Magno Machado" <[EMAIL PROTECTED]> wrote: > What's the point on running the application on desktop if it will run in the > exact same way that it would do on browser?I mean... If the desktop app will > look exactly equals to the browser version, with the same look and feel, > same functionalities, it's better to not have a desktop version at all 1) saving 50% of development effort due to being able to write only one codebase. 2) more robust development cycle on the web app (_proper_ java compiler checking) 3) GWT 1.5's widget API is near-identical to GTK2 and PyQT4 widget API. if you believe that a "browser version" is somehow inferior to "desktop versions", then you either have access to an unbelievably good desktop widget set, or you have a limited idea of what GWT is capable of, perhaps due to the assumption that "if it's web, it has to be HTML + AJAX + CSS, and therefore it must be awful, because by comparison to _good_ desktop widgets, AJAX and HTML programming is bloody awful". for the python programmers it's definitely the case that GTK2, PyQT4 and wxWidgets - the leading acceptable widget sets - are _much_ poorer in quality than what GWT 1.5's Widget set offers (ported to python). whilst i realise that that's a pretty bold statement, it _does_ have basis in fact - i did a port of pyjamas using both GTK2 and PyQT4 and they both failed (hence why i went to webkit). see this: http://mail.python.org/pipermail/python-list/2008-October/511375.html however, i fully appreciate that in the java world, you may have access to infinitely superior desktop widget sets and frameworks. that having been said, i think it does a disservice to the idea of GWT- Desktop, to make the statement that you do, because, as pyjamas- desktop shows, it's perfectly possible, and provides a very _good_ desktop development framework. the ironical thing is that i even have the same bugs present (dialog box handling) in pyjamas-desktop as in pyjamas. l. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: GWT port to Desktop
On Oct 27, 2:51 am, "Ian Bambury" <[EMAIL PROTECTED]> wrote: > If you gave a practical example it might help people understand the benefits ian, hi, i do know what you mean. however, it is quite hard to give a practical example when what you're talking about is that the entire GWT application - unmodified - /unmodified/ - could run as a desktop app, if a GWT-Desktop library existed. :) so - it actually doesn't matter what example you pick. the principle is: _any_ GWT application would also run under GWT-Desktop. just as java, not javascript. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: GWT port to Desktop
On Oct 27, 9:35 am, Thomas Broyer <[EMAIL PROTECTED]> wrote: > > 2008/10/27 Guy Rouillier <[EMAIL PROTECTED]> > > > > Ross, you are thinking too narrowly. Think of a single code base. When > > > it runs on the desktop, it has access to local file system and other OS > > > facilities. When it runs in a browser like GWT does today, it degrades > > > nicely and only loses minimal functionality. Write once, run anywhere. > > You can already do it at no cost (i.e. no need to rewrite GWT in pure > Java) with Adobe AIR or Mozilla Prism. ... yes... by running the GWT-auto-generated javascript, rather than compiling and running the java [linked with the as-yet-to-be-ported GWT-desktop-libraries]. thus, as a developer, you have lost the advantage of being able to find errors at compile-time, because you're still running the javascript. i immediately found a good 20-30 errors the moment i used pyjamas- desktop to run the kitchensink examples and the library itself, because i was being presented with a proper python runtime. missing arguments on function calls. _too many_ arguments on function calls. undefined variables. missing "super" calls. assumptions in string / integer conversions (printf). _none_ of these things were found with the python-to-javascript compiler, or when running with javascript, because javascript is far too permissive. so there are significant _development_ advantages. l. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: GWT port to Desktop
On Oct 26, 10:16 pm, ross <[EMAIL PROTECTED]> wrote: > this thread makes me laugh :) > > I will continue to : > > -use pyjamas only in bed i _love_ talking about pyjamas because i get advertised about women's nightwear with googlemail. > -use GWT for building my sizzling new web app > -use J2SE to write desktop applications > > but i'm curious to see where you guys head with this :) Limiting your > desktop application to run on a JRE equivalent to that which is > emulated by the GWT will by quite funny. *cackle*. it's not _that_ limited. there is a heck of a lot of stuff that GWT does. and saving development effort, developing a web app and then it near-automatically being a desktop app - surely that's worth something? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: GWT port to Desktop
On Oct 26, 4:18 am, GWBasic <[EMAIL PROTECTED]> wrote: > I don't see the point. GWT is designed to run in a browser; it's designed to run in a browser - and with a little bit of work, can be turned into a _desktop_ widget-set with an *identical* interface. > if you > want to do a true desktop application, there are plenty of desktop > development systems that are much better. do such desktop development systems also allow you to compile the same source code into javascript - unmodified - for running the same application - unmodified - in all major web browsers? > C#, Java, Objective C... > They're a dime a dozen. i repeat: do these dime-a-dozen [desktop] development systems also allow the same apps to run in web browsers, unmodified? > If all you're looking to do is get rid of the browser chrome and give > a GWT application full-control of the window, no. i'm not looking to _get rid_ of the browser, i'm looking to make the GWT widget API a cross-browser AND cross-desktop AND cross-widget set framework. > it's trivial to write a > C# (Windows) and Objective C (Mac) application that will do that. > Both C# and Objective C have browser widgets. > You can make the > browser widget fill up the window and then programmatically direct it > to a URL. If you're ambitious, you can capture new window events, add > drop-down menus, ect. will the application so developed work on linux, MacOSX, windows, embedded ARM-based smartphones, google android, solaris and freebsd? > Something to consider is that all of GWT's I/O needs to go to a web > server. yes. > If you're trying to use GWT for something that will save > files to disk, use a local database, burn CDs, ect, you'll need to use > an embedded web server. This is much more complicated then using a > true desktop development environment. not really, although it is an extremely good point. however, you _should_ be designing your app around an MVC concept of some kind _anyway_. installing a mini web server on loopback, and using JSONRPC or other XMLHTTPRequest-based communications mechanism is a tiny price to pay for being able to have your app run - unmodified - on every major web browser _and_ on every major desktop platform and several embedded ones, too [that can handle java and can handle webkit]. l. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: GWT port to Desktop
On Oct 22, 6:16 am, "Jaco Van Staden" <[EMAIL PROTECTED]> wrote:
> Hi... I just picked up on this thread. How does this work
1) you compile webkit with glib / gobject bindings to its DOM model
https://bugs.webkit.org/show_bug.cgi?id=16401
2) you create Java Bindings to the webkit-glib DOM bindings
3) you go through every line of code in GWT, and wherever you see /-
{ }-/ delineating javascript, you REPLACE it with IDENTICAL code,
written in JAVA, that calls the webkit Java DOM bindings, instead.
this is a fairly mundane and slightly mindless task.
4) you call this library GWT-Desktop
5) you compile your app with the "new" GWT-Desktop library
6) you dance on the ceiling.
> and where can I
> read more about this project?
it's an "enhancement" request - just an idea.
http://code.google.com/p/google-web-toolkit/issues/detail?id=2998&sort=-id
> Is there a way to have GWT code running on
> mobile apps?
i don't see why not.
webkit is fast enough to run on embedded platforms [so if you have
java bindings to webkit, to get access to the DOM model, then it's
perfectly reasonable to have GWT code running native on embedded
platforms]
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Suggestion: GWT port to Desktop
> I known nothing aboutpyjamas, but I'm intrigued about what lkcl has > been discussing. What he has done (and is suggesting could be done with > GWT) is to have a browser-based application (via a Java->Javascript > translater like GWT) and a desktop application (via a direct Java > runtime) derived from the *same* codebase. yep. > Why bother, you ask? * webkit is big, but so are full web browsers. despite being big, webkit is _still_ ported to ARM embedded platforms - and used on Android for example. * webkit is _fast_. * you've cut out the javascript (not entirely) from the equation, thus simplified the development process and speeded up execution. > For your mobile or infrequent users, perhaps a > browser-based solution is preferable. At the same time, people who sit > in front of a stationary desktop system may prefer the look and feel of > a desktop application. With thepyjamasapproach, you can satisfy both > constituents with a single set of code. yep :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: GWT port to Desktop
On Oct 17, 3:37 pm, "Arthur Kalmenson" <[EMAIL PROTECTED]> wrote: > You could also use something like Prism *goes off to look up prism*... > or Fluid to run it as a "desktop" app. [i'll look that one up later] ok - prism appears to be a thin wrapper around XULrunner. XULrunner is the "engine" behind firefox, of which firefox _happens_ to be _one_ application - albeit quite a big one. prism - as it stands - requires that you run _javascript_. not java. javascript. so, it's not what i'm advocating - i'm advocating running _native_ java - because all of the javascript is replaced [in the as-yet-non- existent-but-advocated GWT-Desktop library]. thus making things that little bit quicker, and that little bit cleaner to work with. you'd have full access to the complete java debugging environment, for a start. i cannot tell you how much damn easier it's been to have _both_ pyjamas-desktop _and_ pyjamas, to work with: they both complement each other. several bugs have been found in pyjamas - missing function parameters and missing "super" initialisations - which are simply... ignored by javascript. several uninitialised variables - again, javascript says "oh, you're undefined - let's pass _that_ into the function" whereas python runtime goes "undefined variable, WARK WARK!" l. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: GWT port to Desktop
On Oct 17, 3:14 pm, Thomas Broyer <[EMAIL PROTECTED]> wrote: > On 17 oct, 15:45,lkcl<[EMAIL PROTECTED]> wrote: > > > > > does anyone want to be able to run applications written for GWT as a > > *desktop* application? > > > if so, port GWT _back_ into pure java, using Java bindings to > > Webkit's DOM model to manage the "screen". > > Or just package your GWT app as an Adobe AIR app (eventually with the > help of GWT-in-the-AIR, but it's not a requirement). > > (disclaimer: I'm the developer of GWT-in-the-AIR) . ... which - and you'll like this - uses webkit! so, ironically, both of us are advocating that the way to run GWT java apps on the desktop is... via webkit :) ok - i should say: if you want a _free software_ - non-proprietary - way to run GWT java apps on the desktop, port GWT to pure-java using webkit glib bindings. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: how is GWT ensuring that Caption on DialogBox works?
On Oct 17, 2:34 pm, "Ian Bambury" <[EMAIL PROTECTED]> wrote: > Are you doing the bit I mentioned from initEventSystem? oh yeah, definitely. after some print statements (from pyjamas-desktop version, which is pure-python) i found that yes, DOM.setCapture() is definitely being called. event-stopping-propagation definitely works, when you try to click outside of the dialog box (when not doing dragging of course). however, the mouseout is going _outside_ the captured element bizarre. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: how is GWT ensuring that Caption on DialogBox works?
On Oct 17, 11:44 am, "Ian Bambury" <[EMAIL PROTECTED]> wrote: > Have a look in the DOMImpl* classes. For example DomImplIE6 has a jsni > method setCapture) which does 'elem.setCapture();' All the other browsers do > it via DOMImplStandard in the first bit of initEventSystem. > > 'months'? it took me 5 minutes :-) :) ok - yes, i found that. well, i was surprised to see elem.setCapture() for DOMImplIE6, but this is on firefox (and webkit) so... i see that the Impl of setCapture stores the elem argument in a global (well, a static within the class) called captureElem. exactly the same thing is being done in pyjamas (a global variable). and it's very clear - capture's not being activated. i haven't yet found out why. bleurgh :) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Suggestion: GWT port to Desktop
On Oct 17, 12:32 pm, walden <[EMAIL PROTECTED]> wrote: > l, > > Your rhetoric is soaring so high I can't understand a word of it. *ROTFL* :) that's a good way to put it. thank you for making me laugh (at myself) > What is it you want? i don't _want_ anything :) > Can you use plain English? ok. does anyone want to be able to run applications written for GWT as a *desktop* application? if so, port GWT _back_ into pure java, using Java bindings to Webkit's DOM model to manage the "screen". ... is that better? :) l. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: how is GWT ensuring that Caption on DialogBox works?
ian, thanks for responding. i really meant, "how, once DOM.setCapture() has been called, does the *implementation* of GWT ensure that that actually does the job it's expected to do". the issue i'm encountering in the python port (pyjamas) is that when the mouse "wanders outside" of the area represented by the caption element (the bar at the top), all bets are off. you'd better not let go of that mouse-down, because, if you do, then when you move the mouse _back_ into the caption area at the top of the dialog, the mouse-move events continue to get captured, but, of course, the dialog keeps moving away from your mouse!! really irritating. i've spent several months trying to track this one down. On Oct 16, 10:13 pm, "Ian Bambury" <[EMAIL PROTECTED]> wrote: > DOM.setCapture (element) - or something like that, or whatever has replaced > it - I haven't had to use if for ages - means that the element can be set to > 'own' all mouse events for a while. > Ian > > http://examples.roughian.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
ANN: Pyjamas 0.3 Released
Pyjamas 0.3, the port of GWT to python, has been released. Pyjamas is a python-to-javascript compiler and AJAX Framework and Widget set. [hey, that's... that's very similar to what GWT is, i _wonder_ where the code came from? :) ] The API for the Widget set is near-identical to that of GWT, with slow progress catching up from the original port 2 years ago (GWT 1.2) to add the additional widgets of GWT 1.5 since then. Also, the Pyjamas API is so startlingly similar to that of pyqt4 and pygtk2 that a sister project has been done, which ports Pyjamas to the Desktop, thanks to WebKit. In this way, applications that conform to the Pyjamas API can be run *unmodified* in both every major web browser and also on the desktop. Including plugins (such as Adobe Flash). [that's very cool. why doesn't GWT do the same thing? :) ] Documentation for Pyjamas - showcase, tutorial, API, can be found at the web sites: http://pyjd.org for Pyjamas-Desktop http://pyjs.org for Pyjamas l. http://lkcl.net --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Suggestion: GWT port to Desktop
folks, hi, as you've no doubt seen, i mentioned in the announcement of pyjamas 0.3 that there's a parallel project, pyjamas-desktop, which is a port of pyjamas to run as a desktop widget set and framework. it works ... incredibly well, thanks to webkit. the way it's done is by some glib / gobject bindings onto webkit. this non-trivial bit of work resulted in being able to manipulate the DOM model in an identical - and i do literally mean function-for- function, concept-for-concept, property-for-property, attribute-for- attribute and object-for-object identical - fashion to that which you would "normally" use javascript for. over 300 glib objects are auto-generated, and over 1,500 "gdom" functions are auto-generated (thank god. it'd be madness to write them by hand) from the webkit IDL files, and, once the API was available, thanks to the auto-generator, it was - incredibly - a matter of 4-5 days for a port of pyjamas to the desktop to be completed. the nice thing about the glib bindings to webkit is that they're in c, and there are as many "interface generators" to wrap glib objects to other programming languages as there are major programming languages. oh look, here's a screenshot of someone who is advocating the java gobject bindings, and _guess_ what example they're showing? webkit!! http://picasaweb.google.com/cgwalters/Screenshots#5230352024470678530 http://java-gnome.sf.net/2.x http://live.gnome.org/JGIR/SampleCode so. i have a question for you. with webkit providing literally _perfect_ corresponding functionality to that which is provided by a web browser, and with the shiny new webkit-glib bindings sparkling and glittering in that magpie- attractive fashion, _and_ with pyjamas-desktop showing that it's perfectly feasible, what's to stop the GWT Widget set from becoming a cross-browser _and_ cross desktop widget set and framework? l. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
how is GWT ensuring that Caption on DialogBox works?
folks, hi, in the pyjamas codebase, the event handling for dialog box drag- moving, on the caption, doesn't fully capture the mouse properly: http://pyjs.org/examples/kitchensink/output/KitchenSink.html#Popups and click "show dialog", then wiggle the mouse around dramatically. you'll find that the cursor does "text selection" of the page, underneath. i've been going over the 1.5 codebase for several months, and i still can't damn well track it down :) some assistance in working out what the heck is going on would be greatly appreciated. l. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
