Re: elastic tabstops implemented for GTK
Hi Alex, everyone On 29/08/2007, Alex Jones [EMAIL PROTECTED] wrote: Hi again, Nick On Fri, 2007-07-13 at 10:46 +0200, Nick Gravgaard wrote: Thanks Alex, The proportional font stuff is really just a nice side effect - this idea has all sorts of nice implications. Off the top of my head, imagine a program like ls that outputs a list of directories and files. At the moment ls needs to be aware of the number of columns of the console to which it is writing, and then it inserts spaces and newlines to make things line up. Resizing the console has no effect on the layout. Now, I haven't gotten round to implementing word wrap yet, but imagine if ls output a simple tab delimited list of directories and files instead, and the console undertood elastic tabstops (with word wrap implemented). Resizing the console would work, as would proportional fonts. Also, imagine how much easier piping between programs becomes when simple tab delimited text streams works like this! There are many other potential uses too :) Nick How is this coming along? Have you opened bugzilla issues on this yet? I really want to start using this! I thought I'd drop you a mail to tell you that I've turned the gedit patch into a proper plugin and made the following fixes: * Other chars than just \n can now terminate paragraphs * Italic and bold characters are now handled properly * The minimum width and padding width values can now be configured using gconf It should be pretty trivial to add the code to anything that uses GtkSourceView, and probably GtkTextView too. Have a look at nickgravgaard.com/elastictabstops/#gedit for more information, and please email me if you have any problems. Cheers, Nick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: elastic tabstops implemented for GTK
On Wed, 2007-09-19 at 08:14 +0200, Nick Gravgaard wrote: I thought I'd drop you a mail to tell you that I've turned the gedit patch into a proper plugin and made the following fixes: * Other chars than just \n can now terminate paragraphs * Italic and bold characters are now handled properly Yay! :D * The minimum width and padding width values can now be configured using gconf It should be pretty trivial to add the code to anything that uses GtkSourceView, and probably GtkTextView too. Have a look at nickgravgaard.com/elastictabstops/#gedit for more information, and please email me if you have any problems. Good work, Nick! I am noticing that after so much messing with it, it becomes pretty slow to type and delete characters. Deleting any lines using tabs seems to fix this. It seems as if you might be calculating layout unnecessarily. Also it doesn't seem to work when you have insert spaces instead of tabs enabled in GEdit's preferences, nor does it respect the tab width setting for line indentation. I'm not really sure how you could possibly work around these integration problems, but I thought I would bring them up anyway. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Abstract string properties with getter/setter functions
Hi there,
While implementing abstract properties in Vala we encountered a problem
regarding string properties with getter and setter functions:
public interface Test.MyIface {
public abstract string text { get; }
}
A getter function of an abstract string property looks like:
char* test_my_iface_get_text (TestMyIface* self) {
char* value;
g_object_get (G_OBJECT (self), text, value, NULL);
return value;
}
Property accessors in Vala always return weak references. This leads to
a memory leak in the calling function of the getter.
We want property accessors to return weak references so just redefine
the accessors to return a strong reference is only a last-resort-option.
Since we do not see a way around this (yet) and we could not find an
example with strings in another project. I'm asking here if there is a
nice way around this.
BTW: There are equal issues with properties returning objects only there
you can add a hack into the getter unrefing the object before returning
it. This is not applicable with strings.
cheers,
Raffaele
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: elastic tabstops implemented for GTK
On 19/09/2007, Alex Jones [EMAIL PROTECTED] wrote: On Wed, 2007-09-19 at 08:14 +0200, Nick Gravgaard wrote: I thought I'd drop you a mail to tell you that I've turned the gedit patch into a proper plugin and made the following fixes: * Other chars than just \n can now terminate paragraphs * Italic and bold characters are now handled properly Yay! :D * The minimum width and padding width values can now be configured using gconf It should be pretty trivial to add the code to anything that uses GtkSourceView, and probably GtkTextView too. Have a look at nickgravgaard.com/elastictabstops/#gedit for more information, and please email me if you have any problems. Good work, Nick! I am noticing that after so much messing with it, it becomes pretty slow to type and delete characters. Deleting any lines using tabs seems to fix this. It seems as if you might be calculating layout unnecessarily. I am - to fix this I need to at least cache some information as the file is modified. This will be my next task - improving performance. Also it doesn't seem to work when you have insert spaces instead of tabs enabled in GEdit's preferences, nor does it respect the tab width setting for line indentation. I'm not really sure how you could possibly work around these integration problems, but I thought I would bring them up anyway. If you remove all the tab characters from a file the text widget will not have any text after a tab character to align with a tabstop, so it cannot work. That said, it is possible to operate in an environment where the coding standard mandates spaces: the python plugin that converts files between the different formats can be told to do this automatically on loading/saving files (converting from spaces on loading and to spaces on saving). The tab width setting is taken into account when doing this. Nick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On 9/19/07, Raffaele Sandrini [EMAIL PROTECTED] wrote:
Ok i see there is need to clarify things.
On Wed, 2007-09-19 at 17:53 +0200, Tim Janik wrote:
On Wed, 19 Sep 2007, Raffaele Sandrini wrote:
Hi there,
While implementing abstract properties in Vala we encountered a
problem
regarding string properties with getter and setter functions:
public interface Test.MyIface {
public abstract string text { get; }
}
A getter function of an abstract string property looks like:
char* test_my_iface_get_text (TestMyIface* self) {
char* value;
g_object_get (G_OBJECT (self), text, value, NULL);
return value;
}
Property accessors in Vala always return weak references. This leads
to
a memory leak in the calling function of the getter.
i'm not sure what you mean with weak/strong references when it
comes to strings. in C, pointers can be handed out which point to
0-terminated char arrays that represent strings. there's on reference
counting for strings in C as there is in C++. per convention,
for glib/gtk programs, some such string pointers must be g_free()-ed
once.
With strong/weak references is talk about ownership. If some code needs
ownership over a string it will dup the string.
callers of getters have to free the returned string in C.
for glib/gtk programs, if the caller doesn't need to free the string,
the return value should be G_CONST_RETURN gchar*.
That's right since the getters do not claim ownership they do not need
to free the strings. The problem is the caller assumes a weak reference
and will dup it if it needs ownership.
The point here is that we are talking about *abstract* properties i.e. i
do not know whether the implementation uses a static string or not. I
have to call g_object_get whether i want to or not.
We want property accessors to return weak references so just redefine
the accessors to return a strong reference is only a
last-resort-option.
requesting that all string return types should be const char* is
technically
not possible, because some strings need to be constructed in getters.
people who don't want to deal with these memory allocation issues (const
strings vs. caller-needs-to-free strings) should stay away from C, maybe
even C++, and use python, java, scheme, other-garbage-collected
languages.
Vala needs to deal with this issues to enable users who do not want to
deal with it an easy life.
Since we do not see a way around this (yet) and we could not find an
example with strings in another project. I'm asking here if there is a
nice way around this.
i'm really not sure i understand your problem here...
We need a way to steal the string from the property i.e. to make sure
its not a copy of the original.
It's difficult to imagine how one would enforce this, given that the
implementation has complete freedom to copy the string. The GOB string
getters always returned an allocated string. I'm afraid you may have to
resort to that in general.
BTW: There are equal issues with properties returning objects only
there
you can add a hack into the getter unrefing the object before
returning
it. This is not applicable with strings.
this is not applicable with objects. as soon as you called unref(obj),
the object will be destructed and gone, you can't hand it on any
further,
obj will point to freed memory.
in some rare cases and if you're lucky, the object might stay around
a little longer because someone else could coincidentally hold another
reference. but this can't be relied upon.
a well formed getter implementation might do:
return g_object_ref_sink (g_object_new (MY_TYPE_DATA_OBJECT, NULL));
once you g_object_unref() this return value, it'll be instantly
vaporized with
a crushing noise (if you hooked up pulseaudio via destruction emission
hooks ;)
You can check the ref count first. Take a look at the GtkFileChooser
interface
there this hack is used several times. (and annotated as such)
All we need from you is either a solution or the statement that this is
not possible with gobject properties ;).
Forgot to post the bug against Vala:
http://bugzilla.gnome.org/show_bug.cgi?id=472904
Hope things are more clear now.
cheers,
Raffaele
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Wed, Sep 19, 2007 at 06:48:25PM +0200, Raffaele Sandrini wrote: Since we do not see a way around this (yet) and we could not find an example with strings in another project. I'm asking here if there is a nice way around this. i'm really not sure i understand your problem here... We need a way to steal the string from the property i.e. to make sure its not a copy of the original. The property does not need to be actually backed by a string. It just has to accept a string in the setter and produce a string -- a new string -- in the getter. For instance GtkCellRendererText has properties background wich is a string (write-only though) and background-gdk which is a GdkColor. They are views of same thing and what is this actual internal representation is none of your business. To sum it up, you cannot steal something that is owned by you from the begining. Yeti -- http://gwyddion.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
