On Sat, 2011-10-29 at 17:23 +0200, Benjamin Otte wrote:
> So I want to have OpenGL usage in the "possible" realm, but I want to
> keep it away from the "easy" realm, so that nobody goes "oh, that is
> easy, I'll just write my widget using OpenGL", because that would be
> wrong. You want to use GTK
d by the sounds of it, getting worse), it is hard to
keep justifying that choice.
Regards,
--
Peter Clifton
signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On Mon, 2011-10-17 at 16:53 +0100, Peter Clifton wrote:
> Hi guys,
>
> I've got a bug filed against gEDA/gschem, which I can reproduce here on
> Ubuntu Oneiric, in that it seems the GTK text view widget we use for
> property editing is rendered at zero height with GTK 2.24.
particular minimum size to a GtkScrolledWindow widget (which our text
view is packed in)?
Best regards,
Peter Clifton
signature.asc
Description: This is a digitally signed message part
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail
oseconds stored in a gint64.
>
> Your arguments sound right and a nice upgrade over current APIs.
>
> Maybe add G_USEC_PER_MSEC so it's easy to write milliseconds code.
Much as I am a fan of self-documenting code.. isn't "* 1000" much
shorter and easier?
--
On Mon, 2010-08-30 at 00:50 +0200, Benjamin Otte wrote:
> On Mon, Aug 30, 2010 at 12:03 AM, Peter Clifton wrote:
> > Is there any plans to drop the gdk_color_parse() API? Our circuit board
> > design app (gEDA/PCB) uses that for processing configured colour values
> > to RGB
r circuit board
design app (gEDA/PCB) uses that for processing configured colour values
to RGB values. AUUI, it can also translate X colour names into RGB
values. It would be a shame to have to re-invent / copy all this code
into the application for use with GTK3.
Best wishes,
--
Peter Clifton
y coordinates, or performing some
separate coordinate -> priority mapping step (hard, since new coords are
generated as the algorithm progresses), this doesn't seem to be possible
with your implementation.
Any thoughts?
Best regards,
Peter Clifton
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
yway
> - the fact it fixes the bug ought to help identify a better fix if
> necessary.
>
> Could someone point me to the appropriate place / person to file a bug /
> bug regarding this fix?
>
> Best regards,
>
--
Peter Clifton
Electrical Engineering Division,
Engineering Depa
On Wed, 2009-06-17 at 14:23 +0100, Peter Clifton wrote:
> Hi,
>
> I'm playing with getting inkscape to paste successfully from our
> application (gschem), and have encountered some weird corruption-like
> problems with inkscape not successfully getting the correct list
ue in debugging this would be much appreciated.
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)7729 980173 - (No signal in the lab!)
___
gtk-devel-l
On Mon, 2009-01-26 at 22:09 +, Peter Clifton wrote:
> I can't grep a single reference defining the GSEAL macro
> in /usr/include, nor _g_seal__. Yet magically -DGSEAL_ENABLE makes the
> code compilation break by hiding those members.
>
> Am I being dumb...? What black ma
On Mon, 2009-01-26 at 16:34 -0500, Behdad Esfahbod wrote:
> Peter Clifton wrote:
>
> >> If you want a workaround for now, just access the member as
> >> GSEAL(member_name). I told them the GSEAL macro should use __line__, they
> >> didn't listen :P.
> &
On Mon, 2009-01-26 at 09:59 -0500, Behdad Esfahbod wrote:
> Peter Clifton wrote:
>
> > The way GTK seems to have worked (from my past experience), is I /
> > others write patches, then they sit in Bugzilla and get ignored. I won't
> > pollute this reply with the list
oxy member
function needs to be called (it hooks up some private stuff, and
refcounts etc..), but also manipulates the way a proxy object is
connected. You have to be careful how you override that, and doing so is
probably exploiting implementation details of just how the built-in
connect_proxy functi
On Mon, 2009-01-26 at 10:15 +0100, Mathias Hasselmann wrote:
> Am Montag, den 26.01.2009, 04:03 + schrieb Peter Clifton:
> > Hi,
> >
> > I'm trying to write a subclass of GtkAccelLabel in order to override its
> > source for the accelerator string.
> &g
'm running out of decent arguments against other developers on the team
who want to switch away from GTK, and my own patience is becoming
stretched. I want to love GTK, but sometimes (like tonight) it
frustrates me so very much!
Sorry for the rant..
Any suggestions as to how to fix this
On Wed, 2009-01-14 at 09:19 -0500, Matthias Clasen wrote:
> On Wed, Jan 14, 2009 at 6:56 AM, Peter Clifton wrote:
>
> > There is a comment in the above file regarding why they want this same
> > behaviour that I did, along the lines:
> >
> > We want the "titl
On Wed, 2008-12-31 at 13:13 +, Peter Clifton wrote:
> On Mon, 2008-12-29 at 22:56 -0500, Yu Feng wrote:
> > I've just written a similar widget.
> >
> > You should subclass GtkMenuItem,
> > override toggle_size_request, return zero to the *requistion parameter.
On Fri, 2008-09-26 at 12:57 +0200, Tim Janik wrote:
> On Fri, 26 Sep 2008, Peter Clifton wrote:
>
> > On Fri, 2008-09-26 at 11:44 +0200, Tim Janik wrote:
>
> >> - Change additional defaults as needed, e.g.:
> >>gtk_box_init (GtkBox *self)
> &g
eems kindof silly remove the TINY API for using these old classes,
but have to retain lots of:
if (detect_old_class_names) {
foo;
else
bar;
Since the legacy is still there! Plus the code would presumably run much
faster if you could just do GTK_IS_HBOX() rather than look up the name
by
r-defined widgets to a schematic editor's canvas, and a crash / abort
is NOT what we want when the user hand-edits the XML and makes a
mistake.
Actually, there _was_ a bug in libglade, (now fixed) which caused it to
corrupt memory and crash if passed bad XML. (I discovered it with this
very
, root, domain) )
{
/* Clean up, the parser was unable to load the object */
- g_free(self);
+ g_object_unref(self);
return NULL;
}
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue
On Fri, 2007-08-31 at 21:41 +0200, Milosz Derezynski wrote:
> On 8/31/07, Peter Clifton <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 2007-08-31 at 20:09 +0200, Milosz Derezynski wrote:
> > > Hey Alberto,
> > >
> > > I thought about it further and it w
e mockup.
Could a sensible (IE - like it is at present) tree-view header be
constructed out of similarly conjoined buttons, or is there further
themeing required? (Assuming we could switch off the corner rounding and
pre-lighting at will).
--
Peter Clifton
Electrical Engineering Division,
On Sun, 2007-06-24 at 15:19 +0200, Kristian Rietveld wrote:
> On Tue, Jun 19, 2007 at 12:45:09PM +0100, Peter Clifton wrote:
> > This seems to break the MVC abstraction - if the model changes
> > drastically, I need to know which tree-views are connected so I can
> >
ought not to break
existing API, as old models just won't emit that signal.
(IANAGTKDeveloper, so could be wrong about that).
Regards,
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Avenue,
Cambridge
CB3 0FA
Tel: +44 (0)772
ootprint_picker-crop.png
(Using libsexy), but I prefer the "..." button concept.
Is this something which has similar issues regarding consistent theming?
Regards,
--
Peter Clifton
Electrical Engineering Division,
Engineering Department,
University of Cambridge,
9, JJ Thomson Aven
e a
"list of things with some GType", and make the API which modifies that
list emit "changed", "deleted", "inserted" signals, etc. I coded a
GObject derived class to do most of this.
One thing missing with GList is type safety of course, but if you wa
or example, the code you've posted won't work because the
img_objectdesign widget isn't parented in any other widget.
Take a look at http://www.gtk.org/tutorial/c39.html#SEC-HELLOWORLD it
isn't Visual C++ specific, but ought to ground you in the fundamentals.
Regards,
Peter C
K developers is this:
Does the apparent difficulty in extending, or replicating standard GTK
widgets represent a design limitation of GTK? Can GTK provide some
internals of widgets for use in subclassing - rather than for public
access, like "protected" may be used in C++?
Thanks,
Pet
neral... as a question to the GTK people. How is it possible to
subclass GTK widgets where a lot of the implementation detail is hidden
away like this. I realise there may be no contract to keep the internal
implementation constant, but does this mean the only alternative is to
copy-paste and the code for the whole widget to make the changes wanted?
Peter Clifton
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
set this to the height of the cell, which
(give or take padding errors), appears to do the trick.
I still wounder if the text-view ought to specify a height-request which
is big enough for at least one line though?
Perhaps some properties akin to "fill", "expand", "
renderermultilinetext_start_editing(
GtkCellRenderer *cell,
GdkEvent *event,
GtkWidget*widget,
const gchar *path,
GdkRectangle *background_area,
GdkRectangle *cell_area,
GtkCellRendererState flag
34 matches
Mail list logo
