Re: adding elastic tabstops to a widget

2008-08-22 Thread Owen Taylor
On Tue, 2008-08-19 at 23:39 +0200, Nick Gravgaard wrote:
> Hi all,
> 
> I'm trying to make a proper GTK text editing widget that supports
> elastic tabstops [1] with a view to being able to use it in the near
> future in a PyGTK project (a programmer's text editor), and perhaps one
> day getting it added to GtkTextView or GtkSourceView.
> 
> I have something pretty close to being finished. I've developed it by
> hacking the main Pango and GTK code directly rather than making new GTK
> objects that inherit from the standard objects - I figured I'd get the
> functionality working properly before moving the code into new files. It
> consists of 2 parts:
> 
> 1. Modified PangoTab structure to contain "width" (distance between tab
> characters) and "contents_width" (width of text between tabs) values,
> instead of "location" (distance from left margin to tab).
[...]

> 2. Modified gtktextview.c (or gtktextlayout.c - not sure which is a
> better place) to get and set PangoTabs' width and contents_width values
> as text is inserted/deleted etc. This makes up most of the code.
[...]

I talked with some with Nick about this yesterday on IRC and wanted to
summarize here.

My personal opinion on the elastic tab idea is that it's quite neat, and
if tabs worked that way, my life would be better. But it's hard for me
to see how to get from the way that tabs work now to the elastic tabs
model ... I wouldn't want to commit code that used elastic tabs to a
public project because then it would be indented weirdly for everybody
who didn't have elastic tabs. So, I think it's better to focus on how we
can make it possible to implement an elastic-tabs editor with
GtkTextView rather than adding the feature itself to GtkTextView. 

It turns out that the PangoTab changes are mostly an optimization .. to
be able to use the same structure to set tabs on a PangoLayout as to be
able to store the cached lengths of the different segments of a line.
So, I don't think they are needed in 

It also seems that you should mostly be able to do what is needed for
GtkTextView using the public API from a subclass or application. There
is one missing piece:

 - You need to be able to tell when parts of the GtkTextView are 
   revalidated (that is, layout has happpened for those lines.)

Right now, the only way to do this is to get the not-really-public
GtkTextLayout object for the GtkTextView and connect to it's ::changed
signal. This is hackish from C (requires accessing a non-public
structure field), and much more hackish from Python (I gave Nick some
code using ctypes that manages to pull out the GtkTextLayout with some
effort.) And such hacks won't work at all in GTK+ 3.0. So, I think a
::range-validated signal on GtkTextView would be a good addtion.

It also would be useful to have a way of attaching "user data" to a line
of a GtkTextView. (In this case, what you want to store is a cache of
the segment widths for a line.) It is possible to keep a lookaside data
structure in sync with the GtkTextView, but it's a bit awkward and
inefficient.

- Owen


___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: Translucent Scrollbars

2008-08-22 Thread Philip Van Hoof
On Tue, 2008-08-19 at 18:53 +0300, Kalle Vahlman wrote:
> 2008/8/19 Christian Dywan <[EMAIL PROTECTED]>:
> >
> Before even starting to think of all the layout-related technical
> details, one should stop to think if one really wants interesting
> content to be underneath mouse-usable scrollbars (ie. unreachable) and
> why...

You want it for small screens. That's yet another 20 or more pixels that
you don't waste. 

For example Maemo has ultra thick scrollbars for people who use their
full of mayonaise hanging greasy fingers, while eating French Fries in a
good Belgian Frituur, instead of the Apple-ish stylish stylus.

Some even use ketchup! Or even cheese??!! Strange Canadians and UK
people.

I do it all the times (tapping with my dirty greasy fingers). My devices
look horrible and dirty. Indeed. And I plan to continue doing it too.
(for hygienic reasons, I often clean my device, of course).

I can't hold both food AND stylus pens in my hands. I could try tapping
my Nokia devices's touchscreens with a fries ... though (hmm, that's a
good idea).

But that's why the scrollbar is thick, and as a result my working area
feels smaller.

And why a translucent scrollbar would be useful.


-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be




___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


adding gtk/gobject DOM bindings to webkit - code review and advice needed

2008-08-22 Thread Luke Kenneth Casson Leighton
hi folks,

(message goes out primarily webkit-dev but also gtk-devel-list because
 someone there might be able to give some hints on the gobject code-generation
 being developed.)

background: 
https://lists.webkit.org/pipermail/webkit-dev/2008-August/thread.html
https://bugs.webkit.org/show_bug.cgi?id=16401


embarrassingly, after actually trying to use the - successful - 
event manipulation and javscript-snippeting i added, i found that i was
considering techniques so damn awful, to be able to exchange variables
between the python and the javascript that i couldn't bring myself to do it
ha ha.

so i decided to have a go at the CodeGenerationGObject.pm that alp
kindly posted at https://bugs.webkit.org/show_bug.cgi?id=16401
this is what i have - and what it generates - so far (and i will
update it as i make progress):

   http://lkcl.net/webkit

i won't say that i know what i'm doing, but i know the end-result - sort-of -
so i will meander towards the solution (as usual. eventually).

to speed that random hit-and-miss process, a review and some pointers
would be greatly appreciated.

what, ultimately, should the code look like?

is the "private" classing i'm using appropriate?
should i be placing a pointer-to-the-object-being-wrapped as the
"gobject private class" instead of creating an (otherwise pointless
because i believe it should only contain one member - {Classname}* )
GDOM{Classname}Private struct?

can i pretty much copy the "creation" style of the "JS" code generation?
example: for the createElement function in DerivedSources/JSDocument.cpp
do i just... i assume i do pretty much the same thing.

if so, where do i get an ExecState from? _do_ i need one?  (i suspect
not but confirmation greatly appreciated).

this is horrendous but fascinating in that... horrified "i can't quite
believe how much is going on" kind of way.  it's really addictive :)

l.

p.s. whoever chose perl as the code generator i will strangle them happily
if ever i meet them, and will sleep happier at night, knowing that there is
one less perl advocate on the planet. once the job's done, of course,
because i might need their advice :)

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list


Re: Lacking of a ref-counted string.

2008-08-22 Thread Paul LeoNerd Evans
On Wed, 20 Aug 2008 21:07:39 -0400
"Havoc Pennington" <[EMAIL PROTECTED]> wrote:

> If we think of GLib features as either for C, or for language bindings
> in general, or for vala, this particular feature seems like it would
> be *only* for vala - refcounted strings would be pretty strange in
> plain C, and just overhead for other language bindings that already
> have native string types they have to convert gchar* to.

I personally have quite often wanted refcounted GStrings in "normal"
programs that I've written; i.e. entirely unrelated to VALA.

-- 
Paul "LeoNerd" Evans

[EMAIL PROTECTED]
ICQ# 4135350   |  Registered Linux# 179460
http://www.leonerd.org.uk/


signature.asc
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list