Re: GList empty after iteration?
Am 12.09.2011 21:10, schrieb Craig:
Hi All,
I am confused about GList. My application is parsing a file and creating
midi data with it. I am using GList to store the midi data. I have
created a GtkListStore to view the parsed data (to insure I am parsing
the data properly). So, below I iterate through the GList and copy
the data into a tree view. But, I am shocked to see that after I
iterate through the GList, I cannot iterate through the list again. I
have debugged the list after the iteration with g_list_length(events)
which shows the list length at 0. What is up with this? The first
while loop has data, the second while loop has not data. The code is
below--
GtkTreeIter tree_iter;
events = g_list_reverse(events);
events = g_list_first(events);
while(events)
{
gtk_list_store_append (list_store,tree_iter);
struct midi_event *me = events-data;
gtk_list_store_set(list_store,tree_iter,
0, me-time_stamp,
1, me-event_type,
2, me-message1,
3, me-message2,
-1);
events = g_list_next(events);
}
/// this is where the list appears to be empty
events = g_list_first(events);
while(events)
{
g_print(midi event \n);
events = g_list_next(events);
}
Thanks for any help!
This is because you overwrite events in the first loop until it is
NULL (while (events)). So when you do g_list_first(events)
afterwards, you naturally get NULL back.
You should use another GList pointer to iterate through the list, like so:
GtkTreeIter tree_iter;
GList *l;
events = g_list_reverse(events);
events = g_list_first(events);
for (l = events; l; l = l-next)
{
gtk_list_store_append (list_store,tree_iter);
struct midi_event *me = l-data;
gtk_list_store_set(list_store,tree_iter,
0, me-time_stamp,
1, me-event_type,
2, me-message1,
3, me-message2,
-1);
}
for (l = events; l; l = l-next)
{
g_print(midi event \n);
}
Regards,
Denis
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GList empty after iteration?
On lun, 2011-09-12 at 15:10 -0400, Craig wrote:
I am shocked to see that after I iterate through the GList, I cannot
iterate through the list again.
That's an easy one :-)
while(events)
{
/* [...] */
events = g_list_next(events);
}
You are modifying the list in the loop until g_list_next() returns
NULL ...
/// this is where the list appears to be empty
events = g_list_first(events);
so you are now trying to iterate over an empty list (events == NULL).
You probably want a dedicated variable for the iteration, e.g.
GList *iter;
events = g_list_reverse (events);
for (iter = events; iter; iter = iter-next)
/* do stuff */;
for (iter = events; iter; iter = iter-next)
/* do other stuff */;
Regards,
Florian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GList empty after iteration?
2011/9/12 Craig craigbakal...@verizon.net:
Hi All,
I am confused about GList. My application is parsing a file and creating
midi data with it. I am using GList to store the midi data. I have
created a GtkListStore to view the parsed data (to insure I am parsing
the data properly). So, below I iterate through the GList and copy
the data into a tree view. But, I am shocked to see that after I
iterate through the GList, I cannot iterate through the list again. I
have debugged the list after the iteration with g_list_length(events)
which shows the list length at 0. What is up with this? The first
while loop has data, the second while loop has not data. The code is
below--
GtkTreeIter tree_iter;
events = g_list_reverse(events);
shallowcopy = events;
events = g_list_first(events);
while(events)
{
gtk_list_store_append (list_store, tree_iter);
struct midi_event *me = events-data;
gtk_list_store_set(list_store, tree_iter,
0, me-time_stamp,
1, me-event_type,
2, me-message1,
3, me-message2,
-1);
events = g_list_next(events);
}
/// this is where the list appears to be empty
events = shallowcopy;
while(events)
{
g_print(midi event \n);
events = g_list_next(events);
}
Thanks for any help!
Your first loop ands when your event is zer0. Youn need to use a
second pointer for your second iteration which still points to the
first item in the actual list.
Hope that helps.
Regards
Bernhard
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GList empty after iteration?
Le 12/09/2011 21:10, Craig a écrit :
Hi All,
I am confused about GList. My application is parsing a file and creating
midi data with it. I am using GList to store the midi data. I have
created a GtkListStore to view the parsed data (to insure I am parsing
the data properly). So, below I iterate through the GList and copy
the data into a tree view. But, I am shocked to see that after I
iterate through the GList, I cannot iterate through the list again. I
have debugged the list after the iteration with g_list_length(events)
which shows the list length at 0. What is up with this? The first
while loop has data, the second while loop has not data. The code is
below--
GtkTreeIter tree_iter;
events = g_list_reverse(events);
events = g_list_first(events);
while(events)
{
gtk_list_store_append (list_store, tree_iter);
struct midi_event *me = events-data;
gtk_list_store_set(list_store, tree_iter,
0, me-time_stamp,
1, me-event_type,
2, me-message1,
3, me-message2,
-1);
events = g_list_next(events);
You do this until events stop matching the loop's condition (events),
so until it becomes NULL (e.g. there are no more next). So when you use
events below, it's NULL, and NULL is a valid empty list.
Better user a temporary iter like
GList *iter;
for (iter = list; iter; iter = iter-next) {
/* here use iter-data */
}
Cheers,
Colomban
}
/// this is where the list appears to be empty
events = g_list_first(events);
while(events)
{
g_print(midi event \n);
events = g_list_next(events);
}
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GList empty after iteration?
Hello Craig,
I think this is because after first loop, variable events is NULL,
and you cant get first element of GList from it:
g_list_next() --- Returns : the next element, or NULL if there are no
more elements.
Hi All,
I am confused about GList. My application is parsing a file and creating
midi data with it. I am using GList to store the midi data. I have
created a GtkListStore to view the parsed data (to insure I am parsing
the data properly). So, below I iterate through the GList and copy
the data into a tree view. But, I am shocked to see that after I
iterate through the GList, I cannot iterate through the list again. I
have debugged the list after the iteration with g_list_length(events)
which shows the list length at 0. What is up with this? The first
while loop has data, the second while loop has not data. The code is
below--
GtkTreeIter tree_iter;
events = g_list_reverse(events);
events = g_list_first(events);
while(events)
{
gtk_list_store_append (list_store, tree_iter);
struct midi_event *me = events-data;
gtk_list_store_set(list_store, tree_iter,
0, me-time_stamp,
1, me-event_type,
2, me-message1,
3, me-message2,
-1);
events = g_list_next(events);
}
/// this is where the list appears to be empty
events = g_list_first(events);
while(events)
{
g_print(midi event \n);
events = g_list_next(events);
}
Thanks for any help!
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Sharing the places sidebar between Nautilus and GTK+
Hi Federico, Generally, this sounds like a good plan to me. I have some comments below. On Tue, 2011-09-06 at 17:44 -0500, Federico Mena Quintero wrote: [...] 4. See what common, public interfaces we need. For example, nautilus_window_set_initiated_unmount (sidebar-window, TRUE); seems like it could be replaced with a signal on the GtkPlacesSidebar class, and then Nautilus can start a spinner or whatever when an unmount operation starts. Another common interface would be something like gtk_places_sidebar_select_path (sidebar, file:///foo/selected) to highlight a particular item. IIRC nautilus_window_set_initiated_unmount() is basically a hack to redirect a specific NautilusWindow to $HOME instead of closing it when it's opened at a mount location and the mount disappears as a consequence of being unmounted from inside the same window (as there can be multiple windows in Nautilus pointing to a mount at the same time), so probably this is not something useful to replicate in the single-window GtkFileChooser. 5. See what nautilus-isms *should* be doable with plain GIO, and see if there is anything else that Nautilus needs to do about them via signals; maybe for something like nautilus_file_operations_mount_volume_full (NULL, volume, volume_mounted_cb, G_OBJECT (sidebar)); As far as I remember, the only thing that those nautilus wrappers add to using plain GIO is checking for trash files on the mounted volumes (and prompting to the user a dialog asking if the trash should be emptied before unmounting if so). 6. See what things should be available or not in the file chooser... when dropping files on the shortcuts bar, Nautilus can do nautilus_file_operations_copy_move (uris, NULL, drop_uri, real_action, GTK_WIDGET (tree_view), NULL, NULL); Same thing for nautilus_file_operations_empty_trash (GTK_WIDGET (sidebar-window)); So, first of all we should think about whether this kind of interactions are desirable in a file chooser. I don't think GtkFileChooser should be a full-fledged file manager, so I would just disable e.g. copy/move while porting code to GTK+. On the other hand, other operations like emptying the trash might make sense and exposing them in GTK+ currently means either copying a lot of file operations code from Nautilus into GTK+, or using the DBus org.gnome.Nautilus.FileOperations interface as Alexander suggested. [ I think what I would love to see in my dreams for this is a stateful file operations stack in GIO, allowing to have a central GTK+ UI to display completed/ongoing transfers and notifications embedded in the shell (to be used e.g. for browser/IM file transfers as well), but it looks like a lot of work :) ] One little caveat: that part of Nautilus is GPL, and GTK+ is LGPL, although it *seems* that the places sidebar code may initially have come from GTK+ and then reworked heavily. I haven't checked the history closely. What do we do about this? The git history suggests the initial code for the sidebar was contributed by Jamie McCracken, but it doesn't mention whether it comes from GTK+ [1]. As far as my contribution to that code goes, it's fine for me to relicense those parts to LGPL, but maybe we should ask the other contributors as well. [1] http://git.gnome.org/browse/nautilus/commit/src/nautilus-places-sidebar.c?id=977c0f99380c111749b04c20b34113f635d1d0e7 Cheers, Cosimo ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Sharing the places sidebar between Nautilus and GTK+
Hi Jannis,
On Wed, 2011-09-07 at 01:53 +0200, Jannis Pohlmann wrote:
To be honest, I think we can do better than this. The user experience
offered by the current places sidebar is far from ideal IMHO. In
Nautilus 3.x
* the sidebar has no mount/eject progress indicators,
* the eject buttons do not look/feel clickable, i.e., they don't
change their appearance on hover events,
[ This should have been fixed now if you use a recent enough GTK+ and
Nautilus ]
I realize that, aside from the code still being somewhat rough and
imcomplete, this is nothing we'd want to stuff into GTK+. In
particular, faking the look of a tree view with custom widgets may seem
like a hack to most people (even though standard GTK+ drawing routines
are used). On the other hand it is fun to use and shows how the places
sidebar *could* work IMHO:
* progress indicators for async operations,
* real mount/eject/cancel buttons ('cuz spinners alone are not
enough),
* individual row/button highlighting on hover,
* keyboard navigation works (even switching between rows and
buttons is possible),
I agree with these points, even if some of those might be possible to
implement with cell renderers and a tree view; to me, another added
bonus of not using a GtkTreeView but a custom container and a separate
widget for each row is it allows themes to easily style different rows,
which is used e.g. in the Documents mockup [1] and might not be very
easy to do otherwise.
[1]
http://gitorious.org/gnome-design/gnome-design/blobs/master/mockups/documents/documents-sidebar.png
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Sep 12, 2011, at 9:15 PM, John Ralls wrote: I rebased a local branch off quartz-integration against master and carefully went through all of the changes. There were indeed a couple that didn't have bugs, so I created the bugs and attached the relevant patches. There were some others that were quite old, so I updated the patches on the bugs. That's great! Much appreciated. Now that I seem to have GtkTreeModelFilter under control, I will move back again to Quartz review. thanks, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK and OSX: a call to sanity
On Sep 7, 2011, at 7:26 AM, Federico Mena Quintero wrote:
Now, on technical matters:
I looked quickly at git diff origin/master..origin/quartz-integration
and the diff is very simple:
* A bunch of changes to gdk-quartz and gtk*-quartz.c - I imagine that
these can be merged just as they are, since they don't touch the
platform-independent code at all. I'm sure some of these bits could be
reviewed / prettified by someone who knows a lot of OSX idioms, but it's
better to have them in *now* and polish them later.
* This bit:
--- a/gdk/x11/gdkdevicemanager-xi2.c
+++ b/gdk/x11/gdkdevicemanager-xi2.c
@@ -417,10 +417,6 @@ gdk_x11_device_manager_xi2_constructed (GObject *object)
for (i = 0; i ndevices; i++)
{
dev = info[i];
-
- if (!dev-enabled)
- continue;
-
add_device (device_manager, dev, FALSE);
No idea what that's about.
Not mine, likely due to my having turned off the nightly merges/builds/pushes
until this matter gets sorted.
* Some Makefile.am changes; these could use a quick sanity check.
* Some additions to gtkprivate.h, analogous to what it has for win32 right
now.
* A bunch of #ifndef GDK_WINDOWING_QUARTZ in gtkselection.c, so that
those functions can be implemented in gtkselection-quartz.c instead.
This can probably be made prettier by moving the original functions to a
gtkselection-x11.c or something like that.
Or I could duplicate the whole file, as was done with gtkdnd-quartz.c and
gtkclipboard-quartz.c. I prefer not to do that because any maintenance on the
primary file will cause problems unless it's quickly noticed and the
quartz-specific file is also updated.
There's a larger problem with this, though, worthy of its own thread: Compile
time OS/GDK_WINDOWING checks break the multiple-backend architecture of Gtk3.
Quartz is the worst offender, but there are ifdef OS_WIN32 blocks floating
around too.
* An unused variable in gtkthemingengine.c; should be removed.
* Inconsequential whitespace changes in some .po files; should be
removed.
More out-of-sync-with-master differences.
* A tests/testundecorated.c - no idea.
Related to a crash in Lion with undecorated windows. See bug 655079. There's no
patch to add this to master; I'm not sure whether or not it should be. The fix
has already been committed to master and backported to 2.24, and the bug closed.
In all, it sounds like you could merge all the changes to *quartz*.[ch]
files as they are, and just give a quick look to the rest of the
changes.
As to what is in Bugzilla, is there a quick way to find all the Quartz
bugs to speed up their review? (Or are those patches already in the
quartz-integration branch? I didn't look at individual commits to see
if they had bug numbers.)
I rebased a local branch off quartz-integration against master and carefully
went through all of the changes. There were indeed a couple that didn't have
bugs, so I created the bugs and attached the relevant patches. There were some
others that were quite old, so I updated the patches on the bugs. The bugs in
question are:
514843: gtkfilechooser should be more robust
571582: GtkSelection implementation for quartz.
628936: Minimal change to pass introspection.
657770: Write releaseed memory in gtkdnd-quartz.c
607115: _gtk_key_hash_lookup fails to handle modifiers
658722: Drag and Drop sometimes stops working
658767: Drag and Drop NSEvent is Racy
658772: Directory paths for resource directories are hard coded.
Regards,
John Ralls
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
