Status and future of pessulus in GNOME3?
I just wanted to know if pessulus has any future roadmap? With GNOME3 having changed the lockdown method, is there any plans of implementing a GUI for lockdown? I wanted to take this up as a GSoC project if it is still in any kind of roadmap - official or non-official. - Manish ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
Il giorno gio, 28/02/2013 alle 01.51 -0800, Simon Feltman ha scritto:
On Thu, Feb 28, 2013 at 12:04 AM, Martin Pitt martin.p...@ubuntu.com
wrote:
Nikita Churaev [2013-02-27 23:26 +0400]:
3. Gtk.TextBuffer.set_text(text, length) --- length argument
is useless,
since JavaScript uses UTF-16 and length expects length of
UTF-8 string.
I'm afraid we have to live with little oddities like this. I
think
it's better to stay compatible with the C API and its
documentation,
and all currently existing JavaScript program which use the
API than
breaking API and continuously chasing after weird cases like
that.
I don't think skipping the length arg in this case could work even if
API breakage was acceptable. I assume a skip implies a value of zero
is used and in this case that would not work. A better alternative
would be default value support. This way the oddity can be avoided in
client code without breaking API and in general would be a very nice
feature. However, new code using this would need to specify it only
works with advanced versions of GLib or the libraries providing
defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=558620
-Simon
Uhm, I thought JavaScript ignored extra arguments to a function:
$ gjs
gjs function f (a) { };
gjs f (1, 2, 3);
(no error)
Then, why not changing the JS API to provide only
Gtk.TextBuffer.set_text (text);?
It would break no existing code.
In turn, *.set_text(text) calls the non-exported, private,
two-argument version, by computing the right UTF-8 length.
Something like:
let (f = Gtk.TextBuffer.set_text)
{
Gtk.TextBuffer.set_text = function (text)
{
var l = ... // get the right text length for UTF-8
return f (text, l);
}
}
That way, you also solve a lot of programming errors in locales other
than C, providing an easier interface.
You just need a couple of overrides to do so. Similar functions would be
trivial to manage.
Cheers,
--
Matteo Settenvini
FSF Associated Member
Email : mat...@member.fsf.org
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS/E d--(-) s+: a- C+++ UL+++
P+ L$ E+ W+++ N+ o?
w--- O M- V- PS++ PE- Y+++
PGP+++ t++ 5 X- R+ !tv b+++
DI++ D++ G++ e++ h+ r++ y+
--END GEEK CODE BLOCK--
signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Possible to fix glaring Gjs API issues before GNOME 4?
Because that's a simple case. The length argument is not always at the end.
On Fri, Mar 1, 2013 at 7:03 AM, Matteo Settenvini
matteo...@member.fsf.orgwrote:
Il giorno gio, 28/02/2013 alle 01.51 -0800, Simon Feltman ha scritto:
On Thu, Feb 28, 2013 at 12:04 AM, Martin Pitt martin.p...@ubuntu.com
wrote:
Nikita Churaev [2013-02-27 23:26 +0400]:
3. Gtk.TextBuffer.set_text(text, length) --- length argument
is useless,
since JavaScript uses UTF-16 and length expects length of
UTF-8 string.
I'm afraid we have to live with little oddities like this. I
think
it's better to stay compatible with the C API and its
documentation,
and all currently existing JavaScript program which use the
API than
breaking API and continuously chasing after weird cases like
that.
I don't think skipping the length arg in this case could work even if
API breakage was acceptable. I assume a skip implies a value of zero
is used and in this case that would not work. A better alternative
would be default value support. This way the oddity can be avoided in
client code without breaking API and in general would be a very nice
feature. However, new code using this would need to specify it only
works with advanced versions of GLib or the libraries providing
defaults.
https://bugzilla.gnome.org/show_bug.cgi?id=558620
-Simon
Uhm, I thought JavaScript ignored extra arguments to a function:
$ gjs
gjs function f (a) { };
gjs f (1, 2, 3);
(no error)
Then, why not changing the JS API to provide only
Gtk.TextBuffer.set_text (text);?
It would break no existing code.
In turn, *.set_text(text) calls the non-exported, private,
two-argument version, by computing the right UTF-8 length.
Something like:
let (f = Gtk.TextBuffer.set_text)
{
Gtk.TextBuffer.set_text = function (text)
{
var l = ... // get the right text length for UTF-8
return f (text, l);
}
}
That way, you also solve a lot of programming errors in locales other
than C, providing an easier interface.
You just need a couple of overrides to do so. Similar functions would be
trivial to manage.
Cheers,
--
Matteo Settenvini
FSF Associated Member
Email : mat...@member.fsf.org
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS/E d--(-) s+: a- C+++ UL+++
P+ L$ E+ W+++ N+ o?
w--- O M- V- PS++ PE- Y+++
PGP+++ t++ 5 X- R+ !tv b+++
DI++ D++ G++ e++ h+ r++ y+
--END GEEK CODE BLOCK--
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
--
Jasper
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
gir versioning
Hi, I'm running G3.6, and have updated gnome-desktop to 3.7.90 to test it. After that, gnome-shell doesn't start anymore, crashing in libgnome-desktop: [ 2085.503935] gnome-shell[9772]: segfault at 4 ip eb0eb4b1 sp ffc86bf0 error 6 in libgnome-desktop-3.so.7.0.0[eb0cb000+32000] The problem seems to be that gnome-shell 3.6 links to libgnome-desktop-3.so.4 (from G3.6) but the gir package loads libgnome-desktop-3.so.7 (from G3.7.90). This is just an example with shell and libgnome-desktop, but the problem likely applies in other cases. I wonder if there's a way to avoid this. Perhaps we could bump the version of the gir whenever the SONAME changes, so that we would have e.g. GnomeDesktop-3.0.typelib for G3.6, but GnomeDesktop-3.8.typelib for G3.8. I'm not quite sure if that would help or not, as I'm not familiar with introspection stuff. The idea is 'encode' the SONAME in the gir too, so that we can a) have multiple versions installed simultaneously, and b) the right version is loaded to avoid cases like this. Thoughts? Thanks, Emilio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gir versioning
On Fri, Mar 1, 2013 at 4:17 PM, Emilio Pozuelo Monfort poch...@gmail.comwrote: I wonder if there's a way to avoid this. Perhaps we could bump the version of the gir whenever the SONAME changes, so that we would have e.g. GnomeDesktop-3.0.typelib for G3.6, but GnomeDesktop-3.8.typelib for G3.8. I'm not quite sure if that would help or not, as I'm not familiar with introspection stuff. The idea is 'encode' the SONAME in the gir too, so that we can a) have multiple versions installed simultaneously, and b) the right version is loaded to avoid cases like this. Thoughts? gnome-desktop is not a parallel installable library, and its API/ABI have no stability guarantees...this means that it's not a good idea to install a system-wide version of gnome-desktop different from the rest of GNOME, because things likely won't work. Introspection makes no difference here, but for libraries that have different versions installable in parallel (e.g. GTK 2 and GTK 3) I believe this is already how it works (we generate two different gir/typelibs with different names etc). Cosimo ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Status and future of pessulus in GNOME3?
On Fri, 2013-03-01 at 02:00 -0700, Manish Sinha wrote: I just wanted to know if pessulus has any future roadmap? No, see https://bugzilla.gnome.org/show_bug.cgi?id=691543 andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
