2009/8/19 Kristian Rietveld <[email protected]>: > On Fri, Aug 14, 2009 at 1:40 PM, Alberto Ruiz<[email protected]> wrote: >> 2009/8/14 Kristian Rietveld <[email protected]>: >> As for theming, I've been discussing a bit with Thomas, Carlos and >> Cody. We have reached some sort of consensus that a backwards >> compatible path is possible adding a second vtable for engines, >> checking the vtable size and working out a structured way to poke the >> scene graph representation. However, we need time to try these things >> out. Thomas pointed out that working on a separate theming library >> makes a lot of sense as it would allow reaching a nice API and it >> would help the special purpose GObject baed toolkits around to have >> proper theming as well (say Nbtk, Glitter...). >> >> So I think that we've reached the conclusion that theming shouldn't >> get in the way of the current 3.0 plans, as we don't have time to >> deprecate GtkStyle and introduce something new all at once >> (eventhough, we all would have loved to make it). > > Great to know that progress is being made here. Trying things out > definitely sounds like a good idea. Even though we are now not > planning to deprecate GtkStyle in 3.0, we should have an idea whether > "just sealing it" will provide enough flexibility to migrate to > "something new" at a later stage. I think one of the larger problems > has been the hard-coded array sizes of the arrays containing GdkColors > and GdkGCs (but I am not at all an expert on GtkStyle and theming), > and this limitation should disappear in a properly written accessor > function. Are there more pitfalls that can hold us off from a > successful migration in the future?
>From my point of view, sealing everything theming related, deleting all the deprecated style methods would be a great move. Also, with csw, we could move to a "assumed background is already painted" policy for elements, this should improve the third party usage of element drawing where they have to do dirty hacks to avoid corners being painted for rounded elements (like firefox entries and buttons). But again, this doesn't really stop anything 3.0 Sealing all GtkStyle and other theming related object members will definitively help to prepare a backwards compatible solution, a lot. >> 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 >> has a better picture than me here, Robert? > > Can current gtkrc's and CSS theming files co-exist? I'm not sure who would be able to answer this question, but I guess that at some point they should coexist in some sort of fallback way (if !css => gtkrc), actually the presence of the css would be a good way to figure out which engine should be loaded first. -- Un saludo, Alberto Ruiz _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
