Re: Volunteer
Hi Matthias, For a start, I'll pick up your first suggestion. For your nested scrolling use case, I think it a good start would be a somewhat convincing testcase. In my experience nested scrolling is almost always a source of frustration and best avoided... A test case I was thinking of was to implement an image gallery similar to those on mobile devices: Swiping left and right scrolls between images, pinching would let you zoom, and when you've zoomed such that the image is larger than the area, just dragging lets you scroll the image, until you've reached a boundary, after which you'd start dragging the neighboring image in. I'm actually not even sure if a scrolled windows would be the best way to implement this. Some new features would have to be added anyway: Support for paging (ie. bounce back to a page boundary after the drag is released), support for zooming, and probably an option to hide scrollbars. A problem we would have with paging would be that the start of a page would change when the scrolled window gets resized, and to accomodate to that we would need to automatically scroll the widget while it's being resized. Because page boundaries farther away from the origin might then move much faster than the amount the size of the scrolled window changed, this might give very weird results. In the case of the image gallery, this wouldn't be a problem, because you would always change the size of the children to match the size of the visible area of the outer scrolled window. An option would of course be to use a GtkStack instead, and add support for swiping between pages (as you suggested). Personally, I'd like it if it'd still behaved a bit like a paging scrolled window, ie: it starts scrolling as soon as you start dragging, and bounces to the nearest page when you release the touch (probably taking velocity into account, so a very short but fast swipe will move to the next page). But still, I think that to implement this, we might still need functionality which lets widgets propagate only a part of a drag gesture to its parent widget. Regards, Lieven On Wed, Jun 4, 2014 at 11:13 PM, Matthias Clasen matthias.cla...@gmail.com wrote: Hey Lieven, great that you are interested in helping out ! I'm sure you'll find something interesting to work on. Here's a few ideas: - pick any widget that is currently still using a button press event handler, and convert it to using event controllers instead - add support for switching pages by swipe gestures in GtkStack (probably depending on the transition) - investigate using swipe-from-the-edge for bringing up controls in fullscreen mode - choose any application that could benefit from touch support, and try to implement it using the current GTK+ gesture API (one example might be swipes to show/hide the sidebar in gnome-weather)/ For your nested scrolling use case, I think it a good start would be a somewhat convincing testcase. In my experience nested scrolling is almost always a source of frustration and best avoided... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Volunteer
Hi, I'd like to volunteer to help with gtk development, preferably with improving touch support. I've already submitted the kinetic scrolling improvement fixes not too long ago (still waiting for it to be in git though), so I know the code a bit. Are there any open tickets I could pick up? There are plenty of improvements I can think of, but I guess it's better to stick to the current roadmap. One thing I really think gtk should need though, and which I'd like to help with is this: https://bugzilla.gnome.org/show_bug.cgi?id=731221 but I realize that it's quite a big change, so I guess it first needs to be decided if and how we're going to do it. Regards, Lieven. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: kinetic scrolling in gtk
Hi Sathishreddy, I was already afraid that this was what you were trying to do with. Basically, what you'd want is to have nested scrolled windows, an outer one which only scrolls horizontally, and inside that, multiple scrolled windows (probably in a hbox), which only scroll vertically, and then swiping horizontally should scroll the outer one, while swiping vertically the inner one. Unfortunately, this is currently not supported in gtk, and instead only the inner most scrolled window will listen to your touch actions. I really do think this is something that should eventually be supported by gtk, and so it's probably a good idea to create a ticket in bugzilla, but that probably won't end up in the main version until some time. It may be possible to temporarily hack something, for example, by intercepting touch events, and forwarding them to both the inner and outer scrolled windows. Regards, Lieven. On Fri, May 16, 2014 at 1:40 AM, Sathishreddy Cheemarla sathish15...@gmail.com wrote: Thanks Lieven, I will try and get back to you. Actually my requirement is like mobile phones menu.There on first page grid we have icons for menus ,if we scroll horizontally there are some other icons for menus. eg: for your idea i am attaching the images.if we are in first screen where grid is filled with icon if we scroll the screen horizontally we will get the another grid with different icons. please help me in doing this. On Fri, May 16, 2014 at 12:33 AM, Lieven van der Heide lievenvanderhe...@gmail.com wrote: The reason why you don't have horizontal kinetic scrolling is simply because horizontally, your content fits inside the visible area of the scrolled window. Kinetic scrolling in a direction is only enabled when the corresponding scroll bar is visible. Simply changing the text in Non scrollable widget using viewport to already makes the left most scrolled window smaller, and then you do get both horizontal and vertical kinetic scrolling. On Thu, May 15, 2014 at 2:02 PM, Sathishreddy Cheemarla sathish15...@gmail.com wrote: Thanks Lieven, Its working now.But it is scrolling up/down .Is it possible for left/right also? If yes,please suggest the changes . we have tested attached file. On Thu, May 15, 2014 at 5:21 PM, Lieven van der Heide lievenvanderhe...@gmail.com wrote: Well, all scrolled windows in gtk3-demo should have it (try the tree view on the left for example). Can you try to run the gtk3-demo, and see if it works for you? On Thu, May 15, 2014 at 12:42 PM, Sathishreddy Cheemarla sathish15...@gmail.com wrote: Thanks lieven for reply. We are using touch only for input system.do we need multi touch for this. Please share if any sample codes if you have. Regards Sathish Reddy On May 15, 2014 4:56 PM, Lieven van der Heide lievenvanderhe...@gmail.com wrote: Hi Sathishreddy, Kinetic scrolling should be on by default, but is only used with touch input, so my guess is that may be the reason why you're not seeing it. It's currently not possible to use it with mouse or keyboard input unfortunately. Regards, Lieven. On Thu, May 15, 2014 at 12:14 PM, Sathishreddy Cheemarla sathish15...@gmail.com wrote: Hi All, I am using GTK for my UI development. I want to incorporate kinetic scrolling in my UI design. I found that in GTK+3.4 this feature is incorporated. I am unable to use this feature.Can you please share the sample code to use this feature. -- thanks regards c sathish reddy 9966740149 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list -- thanks regards c sathish reddy 9966740149 -- thanks regards c sathish reddy 9966740149 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Physically based kinetic scrolling
I've created a bugzilla ticked: https://bugzilla.gnome.org/show_bug.cgi?id=729608 Regards, Lieven. On Mon, May 5, 2014 at 2:03 PM, Bastien Nocera had...@hadess.net wrote: Hey, On Mon, 2014-05-05 at 13:58 +0100, Lieven van der Heide wrote: I modified the scrolled windows kinetic scrolling to match the actual physics laws for friction and springs. IMHO, this gives a much more pleasing result. A branch with these changes is at https://github.com/lievenvanderheide/gtk-kineticscrolling I hope that someone can have a look at it, and maybe merge it into the main gtk branch. Very interesting work. You should create a bug in the GNOME Bugzilla, and attached a patch that squashes your 2 commits from your git tree. The patch review will be done in Bugzilla instead. You'll at least want to add a more detailed commit explaining all the changes you've made. Cheers ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: About the Glib porting for My custom os
Ehm, wow, you created your own OS? Compared to that, porting glib to it should be a piece of cake. To get started, I would just disable all files, and get them compiling one by one, and when you get a compilation problem, either implement the required function, or change the code to work using your own libraries. The functionality of most unix functions should be very well documented. As for POSIX, yes glib uses posix quite a lot. And if you make changes to glib, you will have to provide the code (under LGPL as well) to all people that use it. It doesn't have to be in the glib repository per se, but anybody that gets your code should at least have the option to redistribute it, which of course includes it being put in the glib repository. 2008/12/10 Susmith M R (RBEI/ECM1) [EMAIL PROTECTED]: Hai All, I am trying to port Glib for my custom operating system. Is it completely portable? Is Glib implemented using POSIX or what?. Do I have to create a posix subsystem for my os to work with Glib? My operating system is not based on any of the supported os available for Glib. So what should I do to port Glib?. I have my own custom libc,libstdc++,Filesystem io,process,threads etc implementation. Please Help me. And if I do change the source code of this Glib, what will be the after effects of the source code that I have developed? Whether my code has to be released to Glib repo? Lot of questions are there… Please help me. Best regards, Susmith M R Life is not measured by the number of breaths we take, but by the moments that take our breath away. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ 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.
The concept of a copy-on-write string really only makes sense in a language like C++, where classes are copied implicitely all the time. In a reference counted language, the kinds of copies that make naive std::string implementations so suboptimal, are already solved by the structure of the language. Btw, I believe most stl implementations moved away from the copy on write model, because it was really hard to do in a thread safe way, while still supporting the full std::string interface. On 8/21/08, Hubert Figuiere [EMAIL PROTECTED] wrote: On Wed, 2008-08-20 at 20:47 -0400, Yu Feng wrote: First, it is very difficult to manage a string without a reference count. The current vala implementation is to assume that strings are immutable, and to copy the strings almost everywhere where increasing the ref-count should be used. The copying mechanism produces workable code, but doesn't work in a efficient way. This is where it hurts. Maybe having a copy-on-write implementation (in Vala) of the string type is what you want. That way, when you need mutability, you copy. That's the choice made by std::string and Glib::ustring (in glibmm that is incidentaly implemented using std::string) in C++ and transcribe pretty well the usage case. Secondly, vala doesn't introduce any additional dependency other than GLib, to implement it in VALA level, the only way is to embed it in the compiler. A compiler with embeded code to do a ref-counted string doesn't sound nice. This is why I think it should be done at GLib level. That's a design choice, but it seem to be unavoidable to have a runtime library at one point. All the other language have one, more or less. Pascal, Java (libcj), Objective-C, Fortran, C++ and even C. I guess it is no exception for Vala. Hub ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Translucent Scrollbars
Well, isn't the whole point of scrollbars to be able to scroll to stuff that's otherwise hidden (behind something else)? I don't see why it would be a problem to show a piece of the content that would otherwise be hidden at all. As long as scrolling to the sides completely, makes the content fully exposed at the left/top of the scroll bars. In that case of the android example, I can see that it would be a problem, but imagine a scroll view that has both horizontal and vertical scrolling. Then it could work, and could indeed make for a fancy theme. But anyway, it will be really hard to implement it in the current gtk. Maybe you could use the offscreen rendering, to render the part that would otherwise be below the scrollbar, and then blend that into the scroll bar in the theming code. On 8/19/08, Kalle Vahlman [EMAIL PROTECTED] wrote: 2008/8/19 Christian Dywan [EMAIL PROTECTED]: Am Tue, 19 Aug 2008 15:17:10 +0200 schrieb Mathias Hasselmann [EMAIL PROTECTED]: When looking at some Android screen shots[1] I've realized that their scrollbars are translucent. That's a really nice idea IMHO. I wonder if we can implement this feature in GTK+. Ciao, Mathias [1] http://www.spiegel.de/fotostrecke/fotostrecke-34358-7.html#backToArticle=572913 Hey Mathias, your example, and for that matter all screenshots with scrollbars on the linked site, is particularly a web browser. Are you thinking of a web widget only or generally of any widgets in Gtk that can be embedded in scrollbars? The latter might involve non-trivial changes, looking at how isolated scrollbars normally are from their child, there are even thick borders between the child and the scrollbars in the dozen engines/ themes I have tested here when writing this. 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... Then again, for a panned content, scrollbars that are translucent or even on-screen only when panning make perfect sense. However, I suppose such discussions should be deferred to a point in time that GTK+ actually has some notion of panning. Which would be nice, btw. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: my ongoing fantasy of garbage collected C programming
Doesn't inkscape use garbage collection? I assume they must be using some glib stuff as well. You could have a look at how they do it. On 8/6/08, Tim Janik [EMAIL PROTECTED] wrote: On Tue, 5 Aug 2008, Britton Kerin wrote: I've tried several times now to get Hans-Boehm (http://www.hpl.hp.com/personal/Hans_Boehm/gc/) working with gtk, but so far no luck. I found all the stuff about how to build glib to be GC friendly and set env vars and such, and then I rebuild almost all of the lib stack on top of it (except atk and the X libs themselves). I still end up with strange failures and seg faults that go away if I just remove -lgc from the link flags. I don't free anything by hand so its got to be something the GC is doing. I'm hoping that the presence of the gc-friendly build support in glib means that somebody knows how to make this work. I would really love to know how to do it. I won't go into the different gc builds and such that I've tried unless someone is interested. AFAIK, no one has tried to make boehm GC really work with glib gtk+ programs so far. The gc friendly mode that glib has in general just zeros-out certain memory portions before calling free(), so GC-alike leak detectors like e.g. valgrind can do a more accurate job. Depending on how clever your GC implementation is, I'd actually expect quite some real world problems with it trying to collect glib memory. E.g. GLib only stores pointers into the _middle_ of fundamental GType nodes (not the node start) and with GSlice provides its own allocator that cannot be replaced with GC collection (the memory pages allocated by gslice.c:allocator_memalign are also not pointed to directly, a pointer to an admin structure at the page tail is kept instead). Thanks, Britton --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: subwindow-less Gtk+ and offscreen windows
For OpenGL, something we could do is let the OpenGL widget's user render to an offscreen buffer, and when he's done, blit the whole result to the target window. This way, all the stuff like overlapping windows will still work with opengl widgets, like with any other widget. It may have a slight performance impact, but I think it will be really minimal if the blitting is done by the hardware (so no cpu reading back from video mem). Of course we'll have to do a performance test before we implement something like this, but I think it might work. On Mon, Aug 4, 2008 at 11:57 PM, Lieven van der Heide [EMAIL PROTECTED] wrote: I don't think that will work, since the user of the gl widget may want to change the viewport as well, and the coordinates in glViewport are always absolute, not relative to the current one. But anyway, would it really be a problem to just have an X window, only for widgets that really need it, and let normal GTK widgets, like text fields and event boxes do their own clipping? I do agree with Alexander that it would make things a lot more flexible. I only wouldn't know if it's possible without braking API/ABI On Mon, Aug 4, 2008 at 11:33 PM, Cody Russell [EMAIL PROTECTED] wrote: On Sat, 2008-08-02 at 21:35 +0200, Alexander Larsson wrote: * Some operations require an X window id, for example: + glXMakeCurrent() so that you can draw into a window with opengl. You can still draw to the toplevel window, but you can't have GdkOffscreenWindow automatically clip the opengl drawing calls (i think). Would it work if there were a new GL widget that took care of glXMakeCurrent() using the toplevel X window and did glViewport() internally using the widget's coordinates or something? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: subwindow-less Gtk+ and offscreen windows
Well, that copying is completely done inside that widget's code, not the code that uses the widget. There it doesn't matter if we have to do some fancy stuff to take clipping into account. The thing is that we don't want to bother the user of te widget with things like clipping. On Tue, Aug 5, 2008 at 2:50 AM, Cody Russell [EMAIL PROTECTED] wrote: Yeah, you can render your scene to an FBO.. but then you're back to the original problem, aren't you? You have to display it to your window at the widget's position and clipped by the widget's dimensions. Or am I missing something obvious? On Tue, 2008-08-05 at 02:17 +0200, Lieven van der Heide wrote: For OpenGL, something we could do is let the OpenGL widget's user render to an offscreen buffer, and when he's done, blit the whole result to the target window. This way, all the stuff like overlapping windows will still work with opengl widgets, like with any other widget. It may have a slight performance impact, but I think it will be really minimal if the blitting is done by the hardware (so no cpu reading back from video mem). Of course we'll have to do a performance test before we implement something like this, but I think it might work. On Mon, Aug 4, 2008 at 11:57 PM, Lieven van der Heide [EMAIL PROTECTED] wrote: I don't think that will work, since the user of the gl widget may want to change the viewport as well, and the coordinates in glViewport are always absolute, not relative to the current one. But anyway, would it really be a problem to just have an X window, only for widgets that really need it, and let normal GTK widgets, like text fields and event boxes do their own clipping? I do agree with Alexander that it would make things a lot more flexible. I only wouldn't know if it's possible without braking API/ABI On Mon, Aug 4, 2008 at 11:33 PM, Cody Russell [EMAIL PROTECTED] wrote: On Sat, 2008-08-02 at 21:35 +0200, Alexander Larsson wrote: * Some operations require an X window id, for example: + glXMakeCurrent() so that you can draw into a window with opengl. You can still draw to the toplevel window, but you can't have GdkOffscreenWindow automatically clip the opengl drawing calls (i think). Would it work if there were a new GL widget that took care of glXMakeCurrent() using the toplevel X window and did glViewport() internally using the widget's coordinates or something? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
glib cygwin build patch.
Glib currently doesn't build on cygwin. I attached a patch that fixes it. Greets, Lieven van der Heide. glib cygwin build fix.patch Description: Binary data ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Does that really apply for the code you link to? Afaik, if a GPL program uses an LGPL library, it doesn't relicense that library under GPL too, it merely links to it, and leaves it up to the user to make sure the library is available. If this would be the case, than it wouldn't be possible for GPL code to use something like the Windows API or DirectX either. I think the restriction from the link you posted only apply to GPL libraries, but not LGPL. On 3/17/08, Mathias Hasselmann [EMAIL PROTECTED] wrote: Am Montag, den 17.03.2008, 00:31 +0100 schrieb Mathias Hasselmann: I am really wondering what's the reason for FSF claiming, that programs licenced GPL-2 only are not allowed to use LGPL-3 libraries. The LGPL-3 allows non-free, proprietary programs to use LGPL-3 libraries, but excludes free software, licensed GPL-2 only? This sounds absurd to me! Is the FSF spreading FUD with their license matrix? Why doesn't the matrix have footnotes explaining that absurd conflict? Ok, it is not FUD. It seems the problem is, that LGPLv3 imposes additional restrictions not found in the GPLv2. So it isn't the LGPLv3 that forbids LGPLv3 libraries to be used by GPLv2-only programs. It is the GPLv2 which forbids to linking against libraries more restrictive than itself. See http://www.fsf.org/licensing/licenses/gpl-faq.html#v2v3Compatibility for details. In theory LGPLv3 allows addition of exceptions, but they have to be approved by all copyright holders. Doubt this will happen. So only chance for upgrading to a new version of the LGPL is waiting for an FSF approved version of the LGPL, which drops those additional restrictions for GPLv2-only programs. Total insanity... Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Move to LGPL3
Ok, according to the matrix on http://www.fsf.org/licensing/licenses/gpl-faq.html#AllCompatibility it's indeed not allowed, although I don't really understand why. On 3/18/08, Lieven van der Heide [EMAIL PROTECTED] wrote: Does that really apply for the code you link to? Afaik, if a GPL program uses an LGPL library, it doesn't relicense that library under GPL too, it merely links to it, and leaves it up to the user to make sure the library is available. If this would be the case, than it wouldn't be possible for GPL code to use something like the Windows API or DirectX either. I think the restriction from the link you posted only apply to GPL libraries, but not LGPL. On 3/17/08, Mathias Hasselmann [EMAIL PROTECTED] wrote: Am Montag, den 17.03.2008, 00:31 +0100 schrieb Mathias Hasselmann: I am really wondering what's the reason for FSF claiming, that programs licenced GPL-2 only are not allowed to use LGPL-3 libraries. The LGPL-3 allows non-free, proprietary programs to use LGPL-3 libraries, but excludes free software, licensed GPL-2 only? This sounds absurd to me! Is the FSF spreading FUD with their license matrix? Why doesn't the matrix have footnotes explaining that absurd conflict? Ok, it is not FUD. It seems the problem is, that LGPLv3 imposes additional restrictions not found in the GPLv2. So it isn't the LGPLv3 that forbids LGPLv3 libraries to be used by GPLv2-only programs. It is the GPLv2 which forbids to linking against libraries more restrictive than itself. See http://www.fsf.org/licensing/licenses/gpl-faq.html#v2v3Compatibility for details. In theory LGPLv3 allows addition of exceptions, but they have to be approved by all copyright holders. Doubt this will happen. So only chance for upgrading to a new version of the LGPL is waiting for an FSF approved version of the LGPL, which drops those additional restrictions for GPLv2-only programs. Total insanity... Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Pidl - an IDL for GObject boilerplate and language bindings
Sounds good! I am actually mostly interesting in such a system, that could wrap c++ classes, but I guess this system could be extended to do such a thing. Maybe a nice project for one day:) On 2/12/08, Christian Berentsen [EMAIL PROTECTED] wrote: https://launchpad.net/pidl Pidl is an Interface Description Language for GObject C-code with automatic language bindings. The programmer mainly writes '.pidl' files and implementation in C. Much GObject boilerplate is hidden. Language bindings are automatically generated. (Currently for Python, C++ and C#) As we are developing a product relying heavily on GObject, we came to the conclusion that the risk of having every developer handling boilerplate code could become a big maintenance headache. Pidl is still in its infancy and is being evolved on a day to day basis. The system is developed in TDD fashion, with test coverage in Python. Could this be interesting for anybody else writing GObject based software? Current feature summary: Emits C++, Python and C# (and GObject front stubs in C) Supports classes, interfaces, properties, methods, and signals. Supports implementing interfaces in C++ and C# (not yet Python) Enums Errors/Exceptions on methods marked as throwing. (GError marshalled to language exceptions, modelled after dbus-glib) Weak references (Properties only) Inheritance and more. -- Jarl Christian Berentsen Ole Andre Vadla Ravnaas (Pidl core monkeys) ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 64 bitshift bug
Thanks:) On 1/4/08, Mathias Hasselmann [EMAIL PROTECTED] wrote: Am Freitag, den 04.01.2008, 13:17 +0100 schrieb Lieven van der Heide: No, it's just the visual studio compiler, which tends to give warnings for these kinds of common mistakes:) Yes, it is quite obsessive regarding such issues. Wondering if gcc has such a warning switch. But can anybody with commit access change it? it's still not in the svn repo. Done: 2008-01-04 Mathias Hasselmann [EMAIL PROTECTED] Resolve 64 bit-shift bug in g_markup_collect_attributes. Spotted by Lieven van der Heide. * glib/gmarkup.c: Use G_GUINT64_CONSTANT in bit-shift. Ciao, Mathias -- Mathias Hasselmann [EMAIL PROTECTED] Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 64 bitshift bug
No, it's just the visual studio compiler, which tends to give warnings for these kinds of common mistakes:) But can anybody with commit access change it? it's still not in the svn repo. Greets, Lieven van der Heide. On 1/2/08, Ryan Lortie [EMAIL PROTECTED] wrote: I should have known better than this. 'collected' used to be a 32bit integer so I forgot to make the change when I switched it to 64. Please tell me that you weren't actually bitten by this bug... If you were, then I have a good deal of sympathy for your parser :) Note that we have G_GUINT64_CONSTANT () exactly for this purpose Thanks for the good catch. Cheers On Wed, 2008-01-02 at 02:06 +0100, Lieven van der Heide wrote: Hi, In gmarkup.c, there's this line: if ((collected (1 i)) == 0) collected is a 64 bit integer, but 1 i results in a 32 bit integer, which is then converted to 64 bits, for the operator. I assume we just want to test any of the 64 bits, using an index in i, in which case it should be: if ((collected ((guint64)1 i)) == 0) I attached a patch that fixes it. Greets, Lieven van der Heide. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: nmake build fixes for glib.
Can anybody take a look at this? On Dec 14, 2007 3:29 PM, Lieven van der Heide [EMAIL PROTECTED] wrote: Here you go: http://bugzilla.gnome.org/show_bug.cgi?id=503602 Did you have a chance to look at it? Greets, Lieven van der Heide. On 12/12/07, Cody Russell [EMAIL PROTECTED] wrote: On Wed, 2007-12-12 at 17:43 +0100, Lieven van der Heide wrote: Hi, I made some fixes for the nmake makefiles and the win32-fixup.pl script. glib, gmodule, gthread and gobject build fine now. gio and tests don't build yet, but I don't think that's related to the makefiles. Also, right now (in svn), it assume that libiconv and gettext are in a folder called ../get-text-0.40.10 and ../libiconv-1.7 These versions don't seem to be outdated anyway, but instead of changing it to the current version, I just changed it to plain ../gettext and ../libiconv, because I don't think there's really one specific version you want to link to, just as long as it isn't too old (I assume they try to stay API and ABI compatible with older version). This is really awesome! I'll test it out hopefully later today. In the mean time, would you mind opening a Bugzilla bug for this and attaching your patches to it? CC me on the bug, or email me the bug# too. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: nmake build fixes for glib.
Here you go: http://bugzilla.gnome.org/show_bug.cgi?id=503602 Did you have a chance to look at it? Greets, Lieven van der Heide. On 12/12/07, Cody Russell [EMAIL PROTECTED] wrote: On Wed, 2007-12-12 at 17:43 +0100, Lieven van der Heide wrote: Hi, I made some fixes for the nmake makefiles and the win32-fixup.pl script. glib, gmodule, gthread and gobject build fine now. gio and tests don't build yet, but I don't think that's related to the makefiles. Also, right now (in svn), it assume that libiconv and gettext are in a folder called ../get-text-0.40.10 and ../libiconv-1.7 These versions don't seem to be outdated anyway, but instead of changing it to the current version, I just changed it to plain ../gettext and ../libiconv, because I don't think there's really one specific version you want to link to, just as long as it isn't too old (I assume they try to stay API and ABI compatible with older version). This is really awesome! I'll test it out hopefully later today. In the mean time, would you mind opening a Bugzilla bug for this and attaching your patches to it? CC me on the bug, or email me the bug# too. / Cody ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
nmake build fixes for glib.
Hi, I made some fixes for the nmake makefiles and the win32-fixup.pl script. glib, gmodule, gthread and gobject build fine now. gio and tests don't build yet, but I don't think that's related to the makefiles. Also, right now (in svn), it assume that libiconv and gettext are in a folder called ../get-text-0.40.10 and ../libiconv-1.7 These versions don't seem to be outdated anyway, but instead of changing it to the current version, I just changed it to plain ../gettext and ../libiconv, because I don't think there's really one specific version you want to link to, just as long as it isn't too old (I assume they try to stay API and ABI compatible with older version). Greets, Lieven van der Heide. for build folder.patch Description: Binary data for glib folder.patch Description: Binary data ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
process id checking for g_child_watch_source-new
Hi, While working on some bug (not sure yet if it's one in my own app, or in glib), I noticed that if you pass a pid of 0 to g_child_watch_source_new, it doesn't complain right away, and will return a GSource pointer, but if you attach that GSource to a context, it will hang the message loop, because an invalid handle will be passed to WaitForMultipleObjects, somewhere deep in the message loop (I'm using windows). I don't think it should be valid to pass a GPid of 0 to g_child_watch_source_new anyway, so I made a patch that adds some g_return_val_if_fail checking to the mainloop code. The patch is attached to this mail. Greets, Lieven van der Heide. invalid_pid_checking.patch Description: Binary data ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK+ Theming improvements
On 9/1/07, Benjamin Berg [EMAIL PROTECTED] wrote:
On Fri, 2007-31-08 at 13:26 +0200, Lieven van der Heide wrote:
As for the general rendering of widgets, I think the current way of
letting the widget itself do the drawing, using a bunch of primitives
(ie. boxes, frames, etc.), and then letting the theme engines theme
just those primitives, instead of the whole widget, has shown to not
really work. What most theme engines seem to be doing now, is kind of
reverse engeneer those draw calls, and then render the theming in
their own way, which often is quite different from what the widget
actually thought is was drawing.
Most of the time these are special cases as for example making certain
corners rounded, but true.
I think it would be better if each widget just has it's own, specific
rendering class, which has a single function that should render the
complete widget at once. (this way, you kind of get a model/view
seperation inside controls). Themes can then override this rendering
class, and have complete freedom inside the render function of that
rendering class.
This sounds a lot like how QT works (I have not had a very deep look
though). However I don't think that any system should require build time
linking. As desktop environments (GNOME, maemo) and/or applications will
need custom widgets.
I don't really get what you mean with build time linking.
Custom widgets are perfectly possible with this approach. Even more so
than with the current approach. The thing is that the rendering
classes can query any other renderer of other widgets, to which they
forward their rendering. If you for example make a widget that's much
like a treeview, you should still make a specific renderer for that
widget, but make a default implementation that just forwards
everything to the treeview renderer. If a theme does not implement
this new widgets renderer, but it does implement the treeview
renderer, then the theming will still look good on both the treeview,
and on this new widget. If a theme engine decides that it does want to
have separate theming, it can implement the renderer of that new
widget, and render it in a different way completely.
This is a general problem that I have not brought up earlier. But I
wonder how to handle one widget that may have two different modes. An
example that is annoying me right now is the radiobutton. It can not
only be a drawn as normal radio button with an indicator, but also as a
button without an indicator (in eg. GtkRadioToolButton).
In the two different cases you may not only want to have some different
style for the radiobutton, but also for the widgets (label) inside. I
think that we either need to remove any case like this, have the
possibility to style widgets (and their children) based on properties or
need a second independent representation of the UI for theming.
Hm, I don't see a way right now to handle the connected buttons in a
button box with this approach nicely.
http://futurepast.free.fr/buttonbox.png
I think that's pretty much orthogonal to it. It will not solve it, but
it won't prohibit us from using something like that css system for it.
The thing that that css system could do, is to just select the
appropriate renderer, using the appropriate settings, depending on the
widget that's being rendered, and the surroundings of that widget.
Note that a single theme engine can have multiple implementations of
the same renderer class (ie. it can have two button renderers). The
css system can then pick a different renderer if the button is for
example neighboring another button.
Each renderer should also have a default implementation, which renders
the widget in a default way, using lower level rendering classes,
which render things like edges and boxes. If a theme engine doesn't
implement a specific widget's rendering class, but it did implement
the lower level ones, then it will still be rendered using something
that fits your theme (basically in the same way it's supposed to work
now).
It should also be possible for a renderer to use the renderer of
another (more basic) widget ,for example, a treeview could use the
button renderer as the default renderer for it's column headers.
pseudo code for the default renderer of a checkbox:
class CheckBoxRenderer
{
struct Params_s
{
int state;
string label;
}
virtual void render(GdkDrawable target,Params_s params)
{
// default implementation that uses the generic renderer
GenericRenderer generic_renderer = get_renderer(GENERIC_RENDERER);
generic_renderer.render_box(target,Rect(0,0,16,16));
if(params.state)
{
generic_renderer.draw_check(target,Rect(0,0,16,16));
}
generic_renderer.draw_text(target,Point(24,0),params.label);
}
}
In this example, overriding the generic renderer class will let you do
theming in the way it's done right now, overriding
Re: GTK+ Theming improvements
As for the general rendering of widgets, I think the current way of
letting the widget itself do the drawing, using a bunch of primitives
(ie. boxes, frames, etc.), and then letting the theme engines theme
just those primitives, instead of the whole widget, has shown to not
really work. What most theme engines seem to be doing now, is kind of
reverse engeneer those draw calls, and then render the theming in
their own way, which often is quite different from what the widget
actually thought is was drawing.
I think it would be better if each widget just has it's own, specific
rendering class, which has a single function that should render the
complete widget at once. (this way, you kind of get a model/view
seperation inside controls). Themes can then override this rendering
class, and have complete freedom inside the render function of that
rendering class.
Each renderer should also have a default implementation, which renders
the widget in a default way, using lower level rendering classes,
which render things like edges and boxes. If a theme engine doesn't
implement a specific widget's rendering class, but it did implement
the lower level ones, then it will still be rendered using something
that fits your theme (basically in the same way it's supposed to work
now).
It should also be possible for a renderer to use the renderer of
another (more basic) widget ,for example, a treeview could use the
button renderer as the default renderer for it's column headers.
pseudo code for the default renderer of a checkbox:
class CheckBoxRenderer
{
struct Params_s
{
int state;
string label;
}
virtual void render(GdkDrawable target,Params_s params)
{
// default implementation that uses the generic renderer
GenericRenderer generic_renderer = get_renderer(GENERIC_RENDERER);
generic_renderer.render_box(target,Rect(0,0,16,16));
if(params.state)
{
generic_renderer.draw_check(target,Rect(0,0,16,16));
}
generic_renderer.draw_text(target,Point(24,0),params.label);
}
}
In this example, overriding the generic renderer class will let you do
theming in the way it's done right now, overriding the
CheckBoxRenderer will give you complete freedom over the way you want
to render the checkbox
To still be able to set up some generic theming things, that will be used by
On 8/29/07, Benjamin Berg [EMAIL PROTECTED] wrote:
Hello,
So here finally an E-Mail about the GTK+ theming discussion we had at
the start of GUADEC and some things I picked up.
In the discussion CSS had been mentioned a lot of times to a large
extend because of the matching abilities that it has. It is possible to
match on the hierarchy and also neighbours. Neighbour matching is
impossible in GTK+ currently and it would with theming paddings between
widgets. Also in CSS/HTML an item can have multiple classes.
Here are some of the main points/ideas:
* Multiple themes in one application (eg. theme preview, glade)
* Instead of having the support directly in GTK+ create a common
library that can be used by Firefox, OpenOffice and maybe even
KDE/QT
* Don't use pixel sizes -- The maemo people designed the interface
in millimetre, however this is not that useful on a desktop
machine.
* Separating positioning of widgets out of the application, and
into the theme.
* No non-transparent X windows if possible
* 3D widgets, eg. lighting effects, or when rotating workspaces
* Solid animation support and transition effects. (imagine eg. an
animation when a menu item is activated, or handling an opening
expander)
There is also http://live.gnome.org/GTK%2B/NewThemeApi (which needs to
be updated) but I this is a pretty complete list.
I think an interesting thing to discuss is the scope of any system. It
was suggested that the theme should be able to handle large parts of the
UI design. Other things that could be handled by themes include
application graphics (eg. nautilus disk usage pie chart) or the metacity
window frames.
As a way forward it is important to know what a CSS based theme format
might look like. Andreas Nilson has said he could help in this area.
Other than this any ideas and comments are of course welcome.
To help the overall process, I can try to keep the wiki in sync with any
arguments that are brought up.
Benjamin
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: elastic tabstops implemented for GTK
I really like this concept. I haven't tried it myself yet, but it seems to work really well. I don't think we should immediately include it in gtk though, because it's not proven enough yet. If it turns out to be completely useless in the end, then it will only be bloat to gtk, which cannot be removed anymore, because we have to stay backwards compatible. My suggestion would be to just get it included in tools like gedit (either trough a plugin, or directly), and maybe also add it to something like libegg, to make it more popular. If it turns out that people like it, we can include it in gtk. On 8/29/07, Nick Gravgaard [EMAIL PROTECTED] wrote: On 29/08/2007, Gustavo J. A. M. Carneiro [EMAIL PROTECTED] wrote: On Qua, 2007-08-29 at 07:42 +0200, Nick Gravgaard wrote: On 29/08/2007, Alex Jones [EMAIL PROTECTED] wrote: Hi again, Nick On Fri, 2007-07-13 at 10:46 +0200, Nick Gravgaard wrote: Thanks Alex, The proportional font stuff is really just a nice side effect - this idea has all sorts of nice implications. Off the top of my head, imagine a program like ls that outputs a list of directories and files. At the moment ls needs to be aware of the number of columns of the console to which it is writing, and then it inserts spaces and newlines to make things line up. Resizing the console has no effect on the layout. Now, I haven't gotten round to implementing word wrap yet, but imagine if ls output a simple tab delimited list of directories and files instead, and the console undertood elastic tabstops (with word wrap implemented). Resizing the console would work, as would proportional fonts. Also, imagine how much easier piping between programs becomes when simple tab delimited text streams works like this! There are many other potential uses too :) Nick How is this coming along? Have you opened bugzilla issues on this yet? I really want to start using this! I've been busy recently with other stuff, so at the moment I'm still hacking my gedit patch to turn it into a plugin. Paolo Maggi (main gedit developer) told me on the gedit list: In this way it will be easier for other people to experiment with your idea and may be we could start including your plugin in gedit-plugins if the other members of the gedit team agree. See: http://mail.gnome.org/archives/gedit-list/2007-July/msg00035.html Does anyone know the process for getting the elastic tabstop functionality into the official GTK branch? Personally I think this is a terrible idea because it breaks compatibility with other editors. If each editor interprets tabs in its own way, then when you save a file from one editor and open in another one it will appear all wrong. The problem is that indenting is already broken regardless of whether you use tabs or spaces. Tabs are broken because if you don't get the size right things won't line up (appear all wrong), and spaces are broken because you're forcing everyone to use your indentation size. My approach fixes these problems. Watch the video on my site: http://nickgravgaard.com/elastictabstops/ If I add this to anything it will always be an option, so if people don't like it they won't be forced to use it. And how will this look e.g. to Python, which generally doesn't even like tabs? Variable width tabs will likely cause havoc in Python programs... Well, if they aren't using tabs it won't affect them at all. Also, if tabs are being used, the only ones that Python cares about are those at the beginning of the line so we shouldn't have a problem. Now, if you did the exact same thing, but behind the scenes inserted spaces instead of tab characters, then it would be nice. If you look at the plugin I made for gedit (watch the video at the link I mentioned above) you can see that it is possible to convert between elastic tabstops and spaces. You lose some of the advantages this way (you can't manipulate the files using tools like sed and still have everything line up when you load it in the editor), but can work on projects that mandate the use of spaces for indenting/alignment. Nick ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Licensing question related to UTF-8 code in GLib
I'm quite sure that this means that code that's licensed under the ruby license can be relicensed under the gpl, but not the other way around, ie. (l)gpl code cannot be relicensed under the ruby license. For example, the BSD license is said to be compatible with the GPL aswell, but that surely doesn't mean that any gpl code can be relicensed as bsd licensed code. As for glib, it's lgpl, so it's no problem to dynamically link to it, from code that's licensed under the ruby license, but modifying, and/or relicensing glib under the ruby license is probably not allowed. Greets, Lieven van der Heide On 8/27/07, Nikolai Weibull [EMAIL PROTECTED] wrote: Hi! I have written a library [1] that is currently under consideration for (at least partial) inclusion in Ruby 2.0 [2]. I used GLib as a reference implementation while writing this library and I am thus wondering exactly how licensing works in this situation. GLib is released under the LGPL and Ruby is released under its own license [3]. According to the Wikipedia entry [4], the FSF has claimed that: This is a Free Software license, compatible with the GPL via an explicit dual-licensing clause. [5] I thus wonder if there is any issue in including code based on [6] code in GLib in a project licensed under the Ruby license. Thanks! nikolai [1] http://git.bitwi.se/?p=ruby-character-encodings.git;a=summary [2] http://www.ruby-lang.org/en/ [3] http://www.ruby-lang.org/en/LICENSE.txt [4] http://en.wikipedia.org/wiki/Ruby_License [5] http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses [6] For some value of based on, I suppose ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Glib build fixes for visual c++
Hi, I made some buildfixes for glib under visual studio. It's mostly related to gdir.c, which required the dirent.h file, which did seem to be present in the win32 versions of gcc, but not in visual c++. I used the code from http://www.softagalleria.net/dirent/index.en.html, and modified it a bit so that it works with utf-8. I think it's a good idea to just keep this file in the glib repository. Greets, Lieven van der Heide vc_buildfixes.patch Description: Binary data ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
thx:) On 4/27/07, Cody Russell [EMAIL PROTECTED] wrote: Yeah, I committed to svn a couple days ago. On Thu, 2007-04-26 at 23:00 +0200, Lieven van der Heide wrote: Did you get a chance to look at it? On 4/23/07, Cody Russell [EMAIL PROTECTED] wrote: Sorry I didn't respond.. I got it. Thanks, I'll get to this later today, I promise. Thanks! On Sat, 2007-04-21 at 20:51 +0200, Lieven van der Heide wrote: Here you go On 4/20/07, Cody Russell [EMAIL PROTECTED] wrote: Hi Lieven, I'm having troubles with the patch for some reason. Could you maybe just send me a copy of your whole msw_style.c file? / Cody On Sun, 2007-04-01 at 21:46 +0200, Lieven van der Heide wrote: I made a new version which should work with tabs at any side, and also, the stretched packing seems to work fine now. My patch is still against revision 17429. Maybe someone can test it, and if it works I can merge it with cody's changes (It will probably conflict if I do an update right now). On my computer, GPS looks fine aswell. If you still have those problems, could you make a screenshot of it? I will have a look at the notebook source to see how the rectangle is calculated, and try to match it in the theming code. -- Cody Russell http://www.gnome.org/~bratsche/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
Did you get a chance to look at it? On 4/23/07, Cody Russell [EMAIL PROTECTED] wrote: Sorry I didn't respond.. I got it. Thanks, I'll get to this later today, I promise. Thanks! On Sat, 2007-04-21 at 20:51 +0200, Lieven van der Heide wrote: Here you go On 4/20/07, Cody Russell [EMAIL PROTECTED] wrote: Hi Lieven, I'm having troubles with the patch for some reason. Could you maybe just send me a copy of your whole msw_style.c file? / Cody On Sun, 2007-04-01 at 21:46 +0200, Lieven van der Heide wrote: I made a new version which should work with tabs at any side, and also, the stretched packing seems to work fine now. My patch is still against revision 17429. Maybe someone can test it, and if it works I can merge it with cody's changes (It will probably conflict if I do an update right now). On my computer, GPS looks fine aswell. If you still have those problems, could you make a screenshot of it? I will have a look at the notebook source to see how the rectangle is calculated, and try to match it in the theming code. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
That would be great. I still have to make a version that applies to 2.10.11 for Arnaud, but I didn't have a lot of time lately. I will try to do it tonight. Greets, Lieven van der Heide On Thu, 19 Apr 2007 23:39:23 +0200, Cody Russell [EMAIL PROTECTED] wrote: On Sun, 2007-04-01 at 21:46 +0200, Lieven van der Heide wrote: I made a new version which should work with tabs at any side, and also, the stretched packing seems to work fine now. My patch is still against revision 17429. Maybe someone can test it, and if it works I can merge it with cody's changes (It will probably conflict if I do an update right now). On my computer, GPS looks fine aswell. If you still have those problems, could you make a screenshot of it? I will have a look at the notebook source to see how the rectangle is calculated, and try to match it in the theming code. Sorry, I overlooked this message until now and just found your latest patch. I will review this patch really soon, and if it looks okay I'll get it committed to svn. Thanks a lot! ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Wimp tab rendering patch
Hi, I made a patch for the windows theme engine, that adjusts the clip rectangle of the notebook buttons a bit. Now it resambles the native windows look more closely, and it fixes the gap between the left edge of the page and the left edge of the button, when the leftmost page is selected. I attached the patch, and an image that shows the difference. Greets, Lieven van der Heide -- Using Opera's revolutionary e-mail cient: http://www.opera.com/mail/ wimp-tab-rendering.patch Description: Binary data beforeafter.PNG Description: PNG image ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Wimp tab rendering patch
I just noticed those problems with different alignments aswell. I will try to fix them. About the different results, could you give me the code you use to create your notebook, so I can see if it gives the same results on my computer, and if it does, try to fix it? Greets, Lieven van der Heide On Sat, 31 Mar 2007 21:43:09 +0200, Arnaud Charlet [EMAIL PROTECTED] wrote: I made a patch for the windows theme engine, that adjusts the clip rectangle of the notebook buttons a bit. Now it resambles the native windows look more closely, and it fixes the gap between the left edge of the page and the left edge of the button, when the leftmost page is selected. I do not really get the same effect applying your patch locally: instead I see the tab displayed one pixel too high. Also, your patch makes the situation worse when tabs are put at the bottom (instead of top), see related PR: http://bugzilla.gnome.org/show_bug.cgi?id=399253 Arno -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
