> successful migration in the future?
>
>> There's the issue of CSS though. Would it be acceptable to deprecate
>> gtkrc's in the middle of the 3.0 cycle in favor of CSS theming files?
>> This is an area where I'm pretty much blind, prolly Robert Staudinger
&
nts to gtk[rc] compatibility.
Availability
----
http://people.freedesktop.org/~robsta/ccss/
Contributors
* Robert Staudinger
* Thomas Thurman
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On Tue, Aug 4, 2009 at 1:08 AM, Tristan Van Berkom 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 vbox as an
On Mon, Aug 3, 2009 at 12:39 AM, Christian Dywan wrote:
[...]
> I wonder what the API might look like.
>
> gtk_container_get_child_position (GtkContainer* container,
> GtkWidget* child,
> gint* row,
>
On Fri, Jul 31, 2009 at 7:28 PM, Tristan Van Berkom 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 define themselve
e/0.3/
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.gnom
On Fri, Jul 31, 2009 at 6:19 PM, Tristan Van Berkom 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 the theme
On Thu, Jul 30, 2009 at 4:37 PM, Christian Dywan 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 be
> reconsidered.
On Thu, Jul 30, 2009 at 7:06 PM, Tristan Van Berkom 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 where its not
On Tue, Jul 28, 2009 at 3:40 AM, Keith Rarick 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 theme f
Hello,
On Sat, Jul 25, 2009 at 2:04 AM, Keith Rarick 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 best wa
Hi Cody,
On Thu, Jun 11, 2009 at 1:07 AM, Cody Russell wrote:
> I might like to help work on this once my current project is finished, or at
> least further along. I had begun integrating Carlos's StyleContext branch
> with gtkrc parsing, but it really seems like CSS is a better direction to
> ta
On Wed, Jun 10, 2009 at 8:58 PM, Alberto Ruiz 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 nobody is
plannin
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. Thi
On Mon, Mar 9, 2009 at 8:44 PM, Owen Taylor wrote:
> On Mon, 2009-03-09 at 15:09 -0400, Behdad Esfahbod wrote:
>> Alberto Ruiz wrote:
>> > 2009/3/2 Behdad Esfahbod :
>> >> Alberto Ruiz wrote:
>> >>> * All drawing funcitions to use a cario context and hide GtkWidget and
>> >>> GdkWindow (Strong req
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 bor
-engine
New in version 0.2
--
* Drawing function logging, see above.
* Resolve special size values: values of -1 for width and/or height
mean the full respective extent of the drawable should be covered.
For an exhaustive list of changes please refer to the ChangeLog.
- Robert
' 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 change
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
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
> r
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 wou
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, an
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", "Gt
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 A
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
> ob
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
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
> ren
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
> pre
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
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
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 t
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]:
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 im
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.
>
>
On Wed, Sep 3, 2008 at 1:25 PM, Alberto Ruiz <[EMAIL PROTECTED]> wrote:
[...]
>> Thinking again, most of the detail strings are actually redundant if
>> the engine is allowed to know what kind of widget is drawn.
>
> No, they are not always redundant, and the engine is allowed actually.
I did no
On Fri, Aug 29, 2008 at 6:13 PM, Benjamin Berg
<[EMAIL PROTECTED]> wrote:
[...]
>> Here's what I learned so far:
>> - The biggest issue is the impedance mismatch between configuring
>> widget style properties in gtkrc while engines are built around
>> drawing primitives.
>
> Not quite sure what y
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 seriou
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 impleme
Hi,
look at http://developer.gimp.org/api/2.0/app/GtkWrapBox.html .
This is what the gimp toolbox uses.
- Rob
On Tue, Jul 8, 2008 at 7:06 PM, Robert Staudinger
<[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Forgive me if this should be on the app devel list. I have a need in
> my
Hello,
as per the established naming standards, wouldn't the define have to
be named G_SEAL(ident) instead of GSEAL(ident)?
Best,
Rob
> Hey All.
>
> As discussed during previous IRC meetings:
> http://mail.gnome.org/archives/gtk-devel-list/2008-June/msg00194.html
> The GSEAL branch has been mer
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 it:
> > Existing implementations too! :)
> >
> > I found the xfce gtk2 engine pretty simple and informative, although
> > Clearlooks didn't look too complex after that either...
> >
>
> I'm interested in the clearlooks one, because I interested in learning
> how to use cairo to perform an engine, so I
On 11/8/05, Tim Janik <[EMAIL PROTECTED]> wrote:
> On Wed, 2 Nov 2005, Robert Staudinger wrote:
>
> > 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
&
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_signa
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 g
45 matches
Mail list logo
