Re: Module Proposal: GNOME Shell
Il giorno mar, 30/03/2010 alle 19.16 -0400, Owen Taylor ha scritto: Dependencies: Mutter: Will be proposed as a desktop release set module GJS: Will be proposed as a desktop release set module gobject-introspection: Will be proposed as a desktop release set module Maybe I've misses it, but are you planning to depend on Clutter 1.2 or 1.4? If the latter, when we'll have a release tarball for jhbuild? :) Cheers, Luca ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
On Tue, 2010-04-06 at 10:54 +0200, Luca Ferretti wrote: Il giorno mar, 30/03/2010 alle 19.16 -0400, Owen Taylor ha scritto: Dependencies: Mutter: Will be proposed as a desktop release set module GJS: Will be proposed as a desktop release set module gobject-introspection: Will be proposed as a desktop release set module Maybe I've misses it, but are you planning to depend on Clutter 1.2 or 1.4? If the latter, when we'll have a release tarball for jhbuild? :) hopefully, Clutter 1.4 will be less problematic to transition to than Clutter 1.2; Clutter 1.4 is still planned to be released following the 2.31/3.0 development schedule - so the API freeze date will be at the end of August like for every other GNOME library. ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
On Tue, 2010-04-06 at 02:52 +0100, Alberto Ruiz wrote: 2010/4/6 Andrew Cowie and...@operationaldynamics.com: Anyway, I think you're on the right track to presume 3D capability, but I don't think we should be so dismissive of concerns from people on less capable hardware or those who are remoting or virtualized. Especially in the later case, that's how lots of people preview things like new Linux releases, so we're exposed to risk of people forming unfortunate first impressions. I think however, that we sometimes underestimate the relevance our own community has, can't we try to approach the nVidia guys as the foundation (maybe with a joint approach with the Linux Foundation guys), and try to help/push them to be GNOME 3 Ready? At the end of the day is a win-win situation as far as I can tell. AfC Sydney ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list I think Alberto's idea of reaching out to nVidia is a great idea - if we can clearly communicate our needs to them it can't hurt to ask. I'd be willing to help reach out to them if needed. Paul ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
On Tue, Apr 6, 2010 at 5:29 AM, Paul Cutler pcut...@gnome.org wrote: I think Alberto's idea of reaching out to nVidia is a great idea - if we can clearly communicate our needs to them it can't hurt to ask. I'd be willing to help reach out to them if needed. Maybe I missed it but why are we only concentrating on Nvidia? Are ATI graphics cards okay vis-a-vis xrand support and others on free drivers? What about Intel? The foundation should probably take a holistic approach to this issue if we want a uniform experience for GNOME 3. I agree this is probably a good course of action. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
Hi! Maybe I missed it but why are we only concentrating on Nvidia? Are ATI graphics cards okay vis-a-vis xrand support and others on free drivers? What about Intel? The foundation should probably take a holistic approach to this issue if we want a uniform experience for GNOME 3. Well, Intel drivers have supported 3D very good recently (despite probably the never ending poulsbo-story). ATI drivers are open source which means we would have to contact the radeon driver developers rather than a company and it is possible to fix things ourselves (more or less). For nvidia, the nouveau driver is still far from stable for 3D and everybody has to use the binary driver. That said, of course we should try to also get in touch with the open source driver developers. Regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoC Proposal: Scripting Framework for Applications
Hi! I am not entirely sure but my guess is adding support for another language would require modifications to all the applications individually that want its support to be included. As far as I have read (I apologize if I am wrong) GObject-introspection just makes language bindings pretty straightforward but to be able to use a language for scripting requires more than bindings; there are other issues involved for example, mechanism for invoking the script, passing objects, data conversion from the scripting language to the language of the application (usually C\C++), etc. That's not true. By adding gobject-introspection you get language-bindings for at least JavaScript and Vala out of the box and python is planned. There is nothing else to do as the bindings are constructed a runtime (vala: compile-time) from the introspection files. The two uses-cases I mentioned are similar to what you are suggesting. In my opinion, these two extremes do seem to have a fair bit of similarity and hence they can be supported using a single scripting framework. Moreover, attempting to unify them would save some code bloat since a single solution is always better than two overlapping ones. Well, would a single solution have so much benefit? Of course you might be able to unify the way plugins are loaded and plugin descriptions are designed but this is actually not much code as most things a handled by GModule anyway. Much more important is the point that any application has it's own plugin API anyway, as the plugins have to interact with the internal architecture of the application. Example: gedit and anjuta both use gtksourceview. But a plugin in gedit is able to interact directly with the gtksourceview class while anjuta supports different editors and as such has an interface called IAnjutaEditor which is used to interact with the editor. A unified framework won't help you here at all. You reinforced my point ;-) . Having a proper scripting framework would avoid having to modify/update each application individually in order to support any new technology in future. Same goes if for example, as you say, python bindings become more mature: individual applications would not have to be updated to add support for this new language. See above. The internal APIs need to be exposed anyway and gobject-introspection is the best way to do it. I wonder what would be left for the Scripting Framework. BTW, could you explain what components this scripting framework should have, which languages it would support, etc.? Regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
On Tue, 2010-04-06 at 11:40 +1000, Andrew Cowie wrote: On Sun, 2010-04-04 at 09:24 -0400, Owen Taylor wrote: Let me phrase it a little differently then - it's not a problem that GNOME is able to fix. If there is demand, I assume NVIDIA will work on xrandr support. Yeah, but given how long NVIDIA has been a part of our community (hey, at least they provided Linux drivers years and years before anyone else did), and given that there are huge numbers of people who have nvidia chips (and sure, it's easy to mock people for not having hardware that runs a non non-free driver, but the reality is most laptops don't give you any choice [or, rather, once you're at the price point and form factor you want, you're unlikely to have any awareness from there] — and most stores encourage customers to buy descrete graphics rather than integrated graphics), and given how long those of us with such chips have been without modern xrandr support despite having made a stink about it, I'm not sure we can expect that they will work on $feature more than they already have. Sure the cards work. Of course they do. But it's awfully jarring to the user experience to have such radically different means for configuring displays between one machine and another. And that's just `gnome-display-properties` vs `nvidia-settings`. Anyway, I think you're on the right track to presume 3D capability, but I don't think we should be so dismissive of concerns from people on less capable hardware or those who are remoting or virtualized. Especially in the later case, that's how lots of people preview things like new Linux releases, so we're exposed to risk of people forming unfortunate first impressions. I don't think I'm being dismissive, what I'm saying is that we can't let the lack of xrandr support in the NVIDIA driver be a blocking issue for creating a modern desktop. As far as NVIDIA is concerned, the only thing they care about is the proprietary driver - they've recently dropped even the pretence of support for the obfuscated 2D-only driver. So GNOME 3 doesn't change anything for them - right now, today anybody using a driver supported by NVIDIA has: A) A non-functional display configuration tool shipped with the operating system B) A very powerful and confusing tool shipped with the driver. The same will be true in GNOME 3, unless things change on the NVIDIA end. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
On Tue, 2010-04-06 at 08:44 -0700, Sriram Ramkrishna wrote: On Tue, Apr 6, 2010 at 5:29 AM, Paul Cutler pcut...@gnome.org wrote: I think Alberto's idea of reaching out to nVidia is a great idea - if we can clearly communicate our needs to them it can't hurt to ask. I'd be willing to help reach out to them if needed. Maybe I missed it but why are we only concentrating on Nvidia? Are ATI graphics cards okay vis-a-vis xrand support and others on free drivers? What about Intel? The foundation should probably take a holistic approach to this issue if we want a uniform experience for GNOME 3. We're generally in much closer contact with the open source driver developers already. They hang out on the same IRC channels, work for the same companies already. There's not really any need for formal contacts there. And the open source drivers generally share much more code and already work pretty consistently - e.g., none of the open source drivers has their own incompatible configuration tool. So, what we want from open source drivers is simply for them to be fast and bug-free when running the shell. But for any sort of outreach to driver developers, whether open source or closed source, you want to be very concrete. This is why getting quantifiable performance numbers is a top priority of mine at the moment. - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoC Proposal: Scripting Framework for Applications
On Tue, 2010-04-06 at 18:24 +0200, Johannes Schmid wrote: Hi! I am not entirely sure but my guess is adding support for another language would require modifications to all the applications individually that want its support to be included. As far as I have read (I apologize if I am wrong) GObject-introspection just makes language bindings pretty straightforward but to be able to use a language for scripting requires more than bindings; there are other issues involved for example, mechanism for invoking the script, passing objects, data conversion from the scripting language to the language of the application (usually C\C++), etc. That's not true. By adding gobject-introspection you get language-bindings for at least JavaScript and Vala out of the box and python is planned. There is nothing else to do as the bindings are constructed a runtime (vala: compile-time) from the introspection files. If I understand you still need to *load* plugins. While gobject-introspection do simplify exporting/importing objects (in runtime or compile time) it does *not* handle loading scripts and running hooks. You still need to add support by hand - otherwise there would be no 'javascript only' gnome-shell. The two uses-cases I mentioned are similar to what you are suggesting. In my opinion, these two extremes do seem to have a fair bit of similarity and hence they can be supported using a single scripting framework. Moreover, attempting to unify them would save some code bloat since a single solution is always better than two overlapping ones. Well, would a single solution have so much benefit? Of course you might be able to unify the way plugins are loaded and plugin descriptions are designed but this is actually not much code as most things a handled by GModule anyway. Much more important is the point that any application has it's own plugin API anyway, as the plugins have to interact with the internal architecture of the application. Example: gedit and anjuta both use gtksourceview. But a plugin in gedit is able to interact directly with the gtksourceview class while anjuta supports different editors and as such has an interface called IAnjutaEditor which is used to interact with the editor. A unified framework won't help you here at all. I'm not quite sure how much code/time is spent on this but you still need to hook the single languages into the stack. Last time I checked C/python/vala was used. gnome-games seems to use a bit guile. If user knows lua/ruby/fortran/shell/javascript - he's out of luck. You reinforced my point ;-) . Having a proper scripting framework would avoid having to modify/update each application individually in order to support any new technology in future. Same goes if for example, as you say, python bindings become more mature: individual applications would not have to be updated to add support for this new language. See above. The internal APIs need to be exposed anyway and gobject-introspection is the best way to do it. I wonder what would be left for the Scripting Framework. BTW, could you explain what components this scripting framework should have, which languages it would support, etc.? I cannot answer for author but I'd imagine that: - Searching plugin directories for plugin - Detecting the language of plugin (ok. assembler is not the language plugin is written in but that's different matter). - Loading/unloading plugins according to given configuration. Setting the python/guile/haskell/lua/tcl/brainf*ck/whitespace/javascript environment. Possibly it should handle dependencies between plugins. Probably languages should be GModule plugins itself. I don't know if it is enough for GSOC project but it is at least so boring task many programs have no more then native+python scripting. Regards signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GSoC Proposal: Scripting Framework for Applications
Hi! You still need to add support by hand - otherwise there would be no 'javascript only' gnome-shell. Well, the shell is javascript-only because it is itself written in javascript. You cannot bind anything to Javascript, you can just bind it to C. gnome-shell is a mutter plugin, mutter is written in C. I'm not quite sure how much code/time is spent on this but you still need to hook the single languages into the stack. Last time I checked C/python/vala was used. gnome-games seems to use a bit guile. If user knows lua/ruby/fortran/shell/javascript - he's out of luck. There may be some code necessary to actually load a plugin but it can also be done in a way that the plugin itself contains some C code (probably just some macros) to behave like a C plugin from the outside and loading its language itself. This part is probably interesting if someone wants to mentor it but it's not really that much work. And keep in mind that plugins usually have metadata files (anjuta uses GKeyFiles) to query information before loading the plugin. Maybe you could write some library that handles the metadata and the loading but it would need to be adapted and added to the gnome code components to be useful. Anyway, if someone would want to mentor it - why not. But it's definitly no scripting framework, it's a plugin library (and there are already a few out there). Regards, Johannes signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
