Re: Control what happens when GtkTextView is resized: keep the bottom part visible
Todor Todorov wrote: Well, since resizing the widget by itself does not do any scrolling, whichever value you get from the adjustment _is_ the current scroll value. In the same way you have the function *_get_upper(), you have *_get_lower() and *_get_value()... Just change the computation however you need it to be. Did you even looked up the functions I used in the API docs? You would have seen the rest You're right, I was wrong about the requirements. I've come to the conclusion that what is necessary is to keep the value (upper - (value + page_size)) constant when resizing happens. This value represents the size of the part of the scrollable widget (a GtkTextView in this case) that remains below the currently displayed portion. That means adjusting the value (which as you said by default is not changed). Well, upper never changes when resizing a widget, so it's only necessary to keep (value + page_size) constant. But page_size _does_ change when resizing happens, so a question very similar to my previous one still holds: is there a way to know the value that the adjustment's page_size had before the resize operation, to compare with the new value caused by the resizing, so that the calculations can be done? I've been able to solve it by storing page_size in a variable at the end of the function and reusing it in the next call, but this is far from elegant. Is there some better way? -- Mere nonexistence is a feeble excuse for declaring a thing unseeable. You *can* see dragons. You just have to look in the right direction. -- John Hasler Eduardo M KALINOWSKI edua...@kalinowski.com.br ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Control what happens when GtkTextView is resized: keep the bottom part visible
I don't believe there is a way to get the size before the change. I do not believe that there is much requirement for that. If you are looking for a more elegant solution, you would have to reimplement GtkViewport or GtkScrolledWindow to keep track of the visible view now and before. Regards, Todor On 11/14/2009 07:10 AM, Eduardo M KALINOWSKI wrote: Todor Todorov wrote: Well, since resizing the widget by itself does not do any scrolling, whichever value you get from the adjustment _is_ the current scroll value. In the same way you have the function *_get_upper(), you have *_get_lower() and *_get_value()... Just change the computation however you need it to be. Did you even looked up the functions I used in the API docs? You would have seen the rest You're right, I was wrong about the requirements. I've come to the conclusion that what is necessary is to keep the value (upper - (value + page_size)) constant when resizing happens. This value represents the size of the part of the scrollable widget (a GtkTextView in this case) that remains below the currently displayed portion. That means adjusting the value (which as you said by default is not changed). Well, upper never changes when resizing a widget, so it's only necessary to keep (value + page_size) constant. But page_size _does_ change when resizing happens, so a question very similar to my previous one still holds: is there a way to know the value that the adjustment's page_size had before the resize operation, to compare with the new value caused by the resizing, so that the calculations can be done? I've been able to solve it by storing page_size in a variable at the end of the function and reusing it in the next call, but this is far from elegant. Is there some better way? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Speeding up thumbnail generation (like multi threaded). Thoughts please.
On Mon, Oct 5, 2009 at 3:05 PM, Mark mark...@gmail.com wrote: On Mon, Oct 5, 2009 at 3:26 PM, Dr. Michael J. Chudobiak m...@avtechpulse.com wrote: On 10/03/2009 02:08 PM, Mark wrote: So what's the conclusion? The existing Nautilus code is OK, except that it should be threaded? That sounds like a good conclusion for now but are we going to do something with it? I'm not a Nautilus developer, but I'd guess that a benchmarked patch against Nautilus would be appreciated... - Mike That will, in time, come. I don't have the time right now or the coming weeks to do that but i will make something somewhere late this month early next month I'm also kinda afraid that speeding up the thumbnailing progress isn't going to speed it up visually because of GTK... right now it seems nautilus is redrawing the window with every change while that might be faster if it only updates once every second.. i might be wrong about that but it's just my visual observation. I have a new benchmark. look at it here: http://img252.imageshack.us/img252/8265/graphs.png What i do find extremely odd is the difference of gdk_pixbuf_new_from_file_at_scale from last time and from now (and i didn't change the glib benchmark so it's just.. faster somehow) Anyway, the new gdk_pixbuf_new_from_file_at_scale benchmark is at 43 seconds. Now the interesting stuff. I made the same benchmark with pure Qt c++ code. No other things. At first the Qt bench was a lot slower but as i went on and tried other things it ended up beating the glib benchmark! the thumbnail quality is exactly the same between both the Qt en the Glib benchmarks. If you want the code for the Qt benchmark look here: http://codepad.org/QuUGHmtr Both benchmarks used thread queues. Another odd thing is that with the last benchmarks (with 70 seconds for the same bench) there was roughly 40% cpu usage if memory serves me well.. Now it was close to 100% (more like 92%) for the Glib and Qt benchmarks.. As for the timings.. it certainly wasn't in memory since i did: sync; echo 3 /proc/sys/vm/drop_caches between every benchmark. Skipping that gave me a time of just 16 seconds! The files are all still the same.. perhaps some packages (like glib and the linux kernel) got updated that might (?) have fixed something somewhere? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: RFC: Adding zlib dependency to libgio
On Mon, Nov 9, 2009 at 4:05 PM, Thiago Macieira thi...@kde.org wrote: As for your argument on living on the same apartment, I disagree a bit. I think we're still at the same building stage, where we share our piping, heating, electricity, we cooperate in the building council, but we haven't yet moved into the same unit. I'm afraid you are condemned to live in the same unit. At least if you want more applications to move in. :-) Another way to see it is from the Innovator's Solution book. The author expresses a theory in which companies and entities go through cycles of interdependency and modularity. I think that applies to us: we're still in the state of interdependency, where the product is not good enough yet and we need a high level of flexibility and the ability to make non-standard interfaces, in order to stay competitive. KDE and GNOME are definitely acting like companies, there are a lot of competitive feelings involved. The problem is, that you are not only trying to build different cars, but also your own roads. This won't turn out well. [...] uncoordinated markets driven by parties working in their own self interest are unable to provide these goods in desired quantities. (http://en.wikipedia.org/wiki/Public_good) Norbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Links to help glib/gtk+ devels and contributors
Hello all, I've created this page [1] with links to bugzilla gtk+/glib bugs. Maybe It's useful for some gtk+/glib developers or contributors. I think that It could improve the patch review process a bit: * You have a quick look of the bugs targeted for the next gtk+/glib release * People interested on one area (performance, quartz/win32 ports...) have a direct link to their bugs. * Official gtk+ devels could take a look at reviewed patches to accept or reject them. * New contributors could take a look at trivial bugs or documentation bugs. Or need-work bugs to improve them. * ...etc I know that all this info can be gathered from bugzilla, but I'm lazy and I prefer direct links ;) Of course, feel free to improve it, but I warn you that the page source is a bit messy ;) Have fun, [1] http://live.gnome.org/GTK%2B/BugzillaLinks -- Javier Jardón Cabezas ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
