* Robert Staudinger
* Thomas Thurman
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On Mon, Aug 3, 2009 at 12:39 AM, Christian Dywanchrist...@lanedo.com wrote:
[...]
I wonder what the API might look like.
gtk_container_get_child_position (GtkContainer* container,
GtkWidget* child,
gint* row,
On Tue, Aug 4, 2009 at 1:08 AM, Tristan Van Berkomt...@gnome.org wrote:
[...]
I think half of that complexity is certainly needed, and the other
half can be reliably introspected.
For instance:
a.) I think its necessary for a customized composite widget author
to be able to mark a
On Fri, Jul 31, 2009 at 7:28 PM, Tristan Van Berkomt...@gnome.org wrote:
[...]
Ofcourse, great example - the way I would suggest implementing this is
a.) we recognize the need to show itemized groups
b.) we define GTK_STOCK_STYLE_ITEM_GROUP
c.) we allow some customized containers
On Thu, Jul 30, 2009 at 7:06 PM, Tristan Van Berkomt...@gnome.org wrote:
[...]
An example of the backwardness we have in place, is that,
IMO its simply wrong to assume the role of a GtkToolbar in a
given application, the toolbar already needs properties to override
theme settings in cases
On Thu, Jul 30, 2009 at 4:37 PM, Christian Dywanchrist...@lanedo.com wrote:
[...]
You are probably aware that gtk_container_get_children () does give yo
the positions of children. Assuming that the lack of guarantees about
order of widgets in a container is the actual problem, maybe this can
On Fri, Jul 31, 2009 at 6:19 PM, Tristan Van Berkomt...@gnome.org wrote:
[...]
The idea of theme writers doing something to the first or last item
of a GtkBox simply based on it being a GtkBox; is a scary idea to me,
while I do recognize the value of exposing the positional data of GtkBox
to
/
eaabdf5115bf004860c7dd538600c5b74ccf4e65cd10e9e83ec4e3d2020b0a01
gtk-css-engine-0.3.0.tar.bz2
490880cff541980476d5c25043022fd4d8d74e1529465e210d99262241ef4ae6
gtk-css-engine-0.3.0.tar.gz
Contributors
Anton Kerezov
Robert Staudinger
Thorsten Wilms
[1] http://www.stellingwerff.com/?page_id=10
[2] http://www.gnome.org
On Tue, Jul 28, 2009 at 3:40 AM, Keith Rarickk...@xph.us wrote:
[...]
What you describe addresses the separation of semantic structure from
presentation, but that approach is far more powerful if the semantic
information is sufficiently rich and sufficiently general. Currently,
writing a gtk
Hello,
On Sat, Jul 25, 2009 at 2:04 AM, Keith Rarickk...@xph.us wrote:
I saw some discussion a while back [1] about using CSS for gtk themes
in the future. Now I have some ideas about that. My apologies if this
isn't the right time or place.
## Pseudo-element Selectors
Last I heard, the
On Wed, Jun 10, 2009 at 8:58 PM, Alberto Ruizar...@gnome.org wrote:
[...]
Carlos it would be nice if you put your stuff upstream so that we can
all start integrating things together and having a public branch with
all the pieces.
Maybe this wasn't clear from my email -- as far as I know
Hello,
seems everyone went back to their cubicles and put the heads down
after the Dublin theming event, so here's a brief update for the CSS
part.
Libccss [1]
---
The CSS library is now used in Intel's Moblin stack, providing CSS
functionality to the clutter-powered netbook toolkit.
On Mon, Mar 9, 2009 at 8:44 PM, Owen Taylor otay...@redhat.com wrote:
On Mon, 2009-03-09 at 15:09 -0400, Behdad Esfahbod wrote:
Alberto Ruiz wrote:
2009/3/2 Behdad Esfahbod beh...@behdad.org:
Alberto Ruiz wrote:
* All drawing funcitions to use a cario context and hide GtkWidget and
On Sun, Oct 26, 2008 at 11:38 PM, Thomas Thurman [EMAIL PROTECTED] wrote:
Several people have raised the idea recently that the responsibility for
drawing window borders might better lie with the application than the
window manager. The idea goes something like this:
1. The window border
' mailing list until the
freedesktop.org services are available.
Development can be tracked via the git repository at
http://anongit.freedesktop.org/git/ccss.git/ .
Credits
---
In alphabetical order:
### Robert Bragg
* Feedback regarding API.
### Robert Staudinger
* Maintainer, all changes
On Wed, Oct 15, 2008 at 12:03 PM, Christian Dywan [EMAIL PROTECTED] wrote:
[...]
Sounds like it would make subclassing kind of hard, if I understand you
right. For instance people like to subclass to create all sorts of
buttons and it is only intuitive that they all look similar. What would
On Wed, Oct 15, 2008 at 3:52 PM, Christian Dywan [EMAIL PROTECTED] wrote:
[...]
thanks for the explanation. I see the idea and I agree, automatic
inheritance doesn't always make sense. However as seem to suggest to
add explicit rules to the theme's gtkrc. I think if we are taking this
route,
On Wed, Oct 15, 2008 at 3:44 AM, Behdad Esfahbod [EMAIL PROTECTED] wrote:
Christian Dywan wrote:
[...]
Right. If we can assign names to widgets (does the a11y layer do something
like that?) then the names can be accessed using the #column-header syntax.
That is IMO the correct way, and
On Tue, Oct 14, 2008 at 11:44 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote:
[...]
Shouldn't the class-specific ones use the css class modifier? That is,
.GtkButton?
The intersection of terminologies is a bit confusing, but it's really
div, p, span etc. in HTML and GtkWindow, GtkButton etc.
On Wed, Oct 15, 2008 at 7:11 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote:
[...]
I still don't buy that. What you want is to make sure GtkPlug style override
that of GTKWindow. And that already happens I assume. *Any* use of
.GtkWindow {...} is wrong, because I may do this in my pygtk code:
On Mon, Oct 13, 2008 at 7:21 PM, Alberto Ruiz [EMAIL PROTECTED] wrote:
[...]
Sure, gotcha, we have taken that scenarios into account already,
however, this is getting a bit off topic since what we were supposed
to discuss here was CSS. I just wanted to raise the point that the
theming API is
On Fri, Oct 10, 2008 at 6:22 PM, Alberto Ruiz [EMAIL PROTECTED] wrote:
[...]
I think that the new API should not allow people to acess to
GtkWidget, this prevents implementation changes since engines end up
depending on Widget implementation details (such as the way containers
are used and
On Mon, Oct 13, 2008 at 2:40 PM, Christian Dywan [EMAIL PROTECTED] wrote:
[...]
I would think, the fact that you are actually trying to preseve
oddities like the GtkTreeView/ GtkButton relation, leaves a bit of a
bad aftertaste. I like the CSS idea, because the most of the syntax is
pretty
On Mon, Oct 13, 2008 at 3:06 PM, Alberto Ruiz [EMAIL PROTECTED] wrote:
[...]
And if you allow engines to access widgets, widgets can only do things
that have been thought of /before/, which is a problem with worst
consequences. Plus, you can easily add that information on the widget
renderer
On Mon, Oct 13, 2008 at 4:58 PM, Alberto Ruiz [EMAIL PROTECTED] wrote:
[...]
It would also be possible to introduce aliases for the sake of
theming, e.g. GtkTreeViewColumnHeader for a GtkButton inside a
treeview. Maybe such an approach would be feasible to bridge the gaps
between the widget
On Fri, Oct 10, 2008 at 3:36 AM, Behdad Esfahbod [EMAIL PROTECTED] wrote:
[...]
Hi Rob,
I got to know about work you are doing by crossing over your fd.o account
request. I thought to myself: wow, this is so cool... why didn't I hear
about this stuff before? I think a good number of
On Mon, Oct 13, 2008 at 5:48 PM, Alberto Ruiz [EMAIL PROTECTED] wrote:
[...]
I can't see why iteration over parents containers is needed in any of
those cases with the proper tools in place. Our current idea is that
containers push that context information into a the widget's context
object
On Tue, Oct 7, 2008 at 11:54 AM, Robert Staudinger
[EMAIL PROTECTED] wrote:
[...]
thanks for pushing this, Alberto.
I'd like to attend and request sponsorship (being a student). Is there
any more formal kind of application required?
For the record, I am withdrawing this request.
Alberto
Hello,
After the CSS engine [1] has gained some traction -- at least in terms
of code -- I'd like to lay out a possible plan for theming in gtk3.
First up, some (well known) issues to consider:
(1) Suboptimal Theming in GTK [2]
(2) Themes are Evil! [3, 4]
(3) Lookalike widget/toolkit
On Wed, Oct 8, 2008 at 3:50 PM, Xavier Bestel [EMAIL PROTECTED] wrote:
[...]
there's another project called [1]Manju (also with code [2]available),
which seems to use SVG instead of CSS. Could you comment on the
differences between these approaches, if you know them ?
Quoting from [1]:
The
On Mon, Oct 6, 2008 at 6:56 PM, Alberto Ruiz [EMAIL PROTECTED] wrote:
Hi there,
we have set the proposed date for the theming API hackfest to the
third week of februrary, this is:
16th-22nd
It'll take place in Dublin, Ireland, hosted by Sun Microsystems at
their headquarters.
The scope
Hello,
while this email is probably not primarily about technical issues, here goes ...
On Thu, Aug 28, 2008 at 3:38 PM, Alberto Ruiz [EMAIL PROTECTED] wrote:
Hello board!
during last GUADEC we had a theming API hackfest and we came up to the
conclusion that there's need for some serious
On Mon, Jul 14, 2008 at 5:42 PM, Alberto Ruiz [EMAIL PROTECTED] wrote:
Hi all,
this is a summary of the issues discussed and the roadmap about a new
theming API for Gtk+ at GUADEC:
Current situation:
Misc:
* Engines are too dependent on widget implementation
Hello,
incidentially just a few days ago I hacked together a small library
that allows embedding of gtk widgets into gecko based browsers (and
presumably others that support the netscape plugin API). It's really
just a quick hack but may serve for prototyping widget/html/css stuff.
How to get
Hi,
in the process of wrapping parts of the c++ mozilla API into gobjects
[1] i came across the limitation of g_object_connect() being not
virtual.
Mozilla heavily uses listener classes that have to be derived from and
handed over to the event source for receiving callbacks. In order to
have the
On 11/2/05, J. Ali Harlow [EMAIL PROTECTED] wrote:
On 02/11/05 17:20:49, Robert Staudinger wrote:
Or am i missing something and it's already possible to get some kind
of notification when a signal is connected on a GObject subclass?
g_signal_has_handler_pending() may help.
Hmm, while
Hello,
in the progress of porting to GtkComboBoxEntry the following things
are not clear to me:
+ Is the changed signal (supposed to be) fired when text is entered
via keyboard and confirmed with enter?
+ Is is possible (without hooking internals) to to get notification
about keystrokes on the
37 matches
Mail list logo
