better practice for work with saved buffer
hello friends, I am working on a gtk_list_store, that will save the rows to a file (set_contents(file, buffer)) After saving the datas to a file, without exiting, I will like to edit the file (as buffer) again. For that I have 2 option in my knowledge: 1) save the data, g_free(buffer), list_store_clear, reload the saved file 2) save the buffer to the file, but continue working with that without g_free(buffer) both seems to work, but which is the better practice? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
CSS Transitions
Hi all, Last week I had a go at adding CSS transitions to Adwaita. It was pretty easy to do, and the familiarity of CSS made it easy to get started. However, I encountered an issue which leaves me uncertain how to proceed. The problem is that CSS doesn't provide a way to specify transitions according to beginning and end states. Instead, each style class can have a transition associated with it, and it is triggered whenever that style appears. I can set an animated transition for pressed buttons, but that animation is used whenever the pressed button style appears, irrespective of the style of the button beforehand. The pressed button transition will be used when a window changes from being unfocused to being focused, for example (in which case all the buttons in the window look like they are being pressed at the same time), or when it changes from being insensitive to being sensitive. As a result of this issue, I'm not sure that I can make use of CSS transitions, which is a shame - the ability to animate between different widget states would definitely add to the user experience. Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSlice vs. tcmalloc vs. jemalloc
tis 2013-05-07 klockan 14:52 -0500 skrev Federico Mena Quintero: On Sat, 2013-05-04 at 22:10 +0200, stefan skoglund(agj) wrote: Do GSlice use the Solaris feature for memory usage levelling (an important feauture because of the fact that the SPARCCenter 2000 had striped RAM.) Important that in this case that if you hit multiple structs of the same type for example a tree-walk you should avoid hitting the same memory bank multiple times in a row. U, do you mean the cache coloring stuff? I.e. so that structs of the same size get put in different cache lines. I don't recall mentions of memory usage levelling; to what does that refer? Federico It is an improper term but yes it is cache coloring functionality. The SPARCCenter2000 was built on two XD-busses (the main system-buss) with all CPU-cards connected to both busses and with equal access to memory for every card (cpu cards can be memory only, with cpus and memory or only cpus.) The memory is striped in 256-bytes stripes on the 2 XD-busses which means that that coloring stuff is even more important. Memory bank in my earlies email = XD-buss ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GSlice vs. tcmalloc vs. jemalloc
On Wed, 2013-05-08 at 15:32 +0200, stefan skoglund(agj) wrote: It is an improper term but yes it is cache coloring functionality. Yes, GSlice implements cache coloring; it works automatically. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: CSS Transitions
On Wed, 2013-05-08 at 10:58 +0100, Allan Day wrote:
Hi all,
Last week I had a go at adding CSS transitions to Adwaita. It was
pretty easy to do, and the familiarity of CSS made it easy to get
started. However, I encountered an issue which leaves me uncertain how
to proceed.
The problem is that CSS doesn't provide a way to specify transitions
according to beginning and end states. Instead, each style class can
have a transition associated with it, and it is triggered whenever
that style appears.
I can set an animated transition for pressed buttons, but that
animation is used whenever the pressed button style appears,
irrespective of the style of the button beforehand. The pressed button
transition will be used when a window changes from being unfocused to
being focused, for example (in which case all the buttons in the
window look like they are being pressed at the same time), or when it
changes from being insensitive to being sensitive.
As a result of this issue, I'm not sure that I can make use of CSS
transitions, which is a shame - the ability to animate between
different widget states would definitely add to the user experience.
I think you can quickly get into prohibitively heavy complexity here,
which is why, presumably, that CSS doesn't try to to have the idea of
start and end states.
If I was handling this on the web, I'd probably do something like,
in setup:
$(button).transitionEnd(
function() {
$(this).removeClass('pressing');
});
When pressed:
$(button).addClass('pressed').addClass('pressing');
In CSS:
.button.pressed { background: red; }
.button.pressing { transition: background 1s; }
I think we possibly should do something similar here. We could do
something like:
gtk_style_context_add_temporary_class(button,
GTK_STYLE_CLASS_PRESSING);
With the semantics of temporary meaning removed when last transition
finishes. I don't think you'd need many of these style classes to allow
most of what the designers want.
A generalization would be to automatically add extra temporary
pseudo-classes on changing state:
.button:active-changing { transition: background 1s; }
Note that you can represent a transition in a particular direction as:
.button:hover:hover-changing
So you don't need to represent that in the pseudo-class, but I'm worried
about the performance implications of having it on, in
particular, :backdrop.
- Owen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list
