Re: GtkFileChooser and GVFS backend
On Wed, 2007-12-19 at 13:25 -0500, Matthias Clasen wrote: > On Dec 19, 2007 4:00 AM, Alexander Larsson <[EMAIL PROTECTED]> wrote: > > > > > Yes, both of these are part of the long-term plan. However, we need to > > have the GtkFileSystem module for the next gnome module, as that will > > have the new glib, but not a new Gtk+. > > Talking about that... > we need a plan for how to handle the gvfs filechooser backend for 2.22. > I think it will be best to put it in libgnomeui, next to (or > replacing) the gnome-vfs backend thats already there. > > After 2.22 we can look at moving it over to gtk itself, or doing something > better. > > Does that sound reasonable ? Sounds reasonable to me. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gfvs] cdda backend
On Wed, 2007-12-19 at 16:43 -0500, David Zeuthen wrote: > > > I'm thinking this can also be used for the "favorite" servers like we > > > have today in gnome-vfs; e.g. we just implement a volume monitor that > > > creates GVolume objects that matches a list in gconf. Then when the > > > mount is actually created the volume monitor adopts the DaemonMount in > > > it's adopt_orphan_mount() function. > > Btw, is this how we should implement it? Or did you have anything else > in mind? I really miss my "public_html @ p.fd.o" link that comes up > automatically - I use it a lot when doing screen shots to share. > > I think if we do the feature this way (a gvfs module that links in > gconf) it can be written in a day or less. Well, Its certainly a good way to implement connect to server as it existed before. However, the question is whether this is the best design in the new gio world. In the pre-gio world there were no "mounts" for a remote share like your example, so it didn't appear anywhere. Connect to server was added to sort of make it into a mount. But in the new world we actually have a mount object, so the need to make it look like there is a mount is gone. However, as you say this is used for another thing, namely easy access to the share. In the gio world this would mean having a GVolume for the GMount so that it is easy to mount. At the very least this would involve changing how connect to server is exposed in the UI and what it is called. There is also how it relates to bookmarks, which is another not-quite-the-same way to quickly get to places. So, I guess the question is, in what way is it better to have "public_html @ p.fd.o" be a volume than using a bookmark for this? > > So, can there never be a situation where the GMount gets created before > > the corresponding GVolume object is? And in that case, how does the > > GVolume locate the mount? > > That's a good question; it's not supported in the API yet because that > situation can never happen for the use I wrote it for (cdda:// backend). > > How about a another vtable entry in the GVolumeMonitor > > gboolean (*request_adoption_of_orphan_mount) (GVolume *adopter, >GMount *orphan); > > that each implementation can implement? Alternatively we can put this > method on the GMount interface but that seems wrong since it's only > something volume monitors would ever want to do. The volume monitor would recurse over all volumes and call this? Isn't it better to have something like: GMount * (*find_orphan_mount_for_adoption) (GVolumeMonitor *monitor, GVolume *adopter) > > > Other thoughts / questions about the API > > > > > > - Busy mounts. Right now the cdda:// backend refuses to unmount > > >if there are open files on it. I think that's probably the right > > >thing to do for any backend. > > Btw, what are you thoughts about this? I feel strongly this is the right > thing to do .. otherwise you can lose data. > > I'd even go as far and say that the GVfsBackend base class should > automatically return G_IO_ERROR_BUSY on unmount() when there are pending > jobs. At least that would be the default unmount() operation unless you > override it. Sure, thats probably a good thing. > > > - Further, if a mount can't be unmounted because it's busy (and > > >we can't avoid that since we support mounts backed by kernel > > >drivers), we probably want something like lsof(8) that Nautilus > > >and other stuff can use to put up a dialog showing what apps > > >is blocking the unmount. How about a list_open_files() method > > >on GMount() that returns an array of > > > - process id (is that portable? maybe need an abstraction) > > > - icon > > > - name > > > - etc. > > >Would need backend support for this too. > > > > Now we're getting into really lowlevel bizarro things. I don't think we > > should really expose this in a generic API. Can't this just be reported > > in the error message for the G_IO_ERROR_BUSY error when unmounting. > > > > I.E. the error dialog would say "Cannot unmount, because firefox (pid > > 35) is keeping files open on the volume", or "Cannot unmount, because 13 > > applications are keeping open files on the volume.". Maybe in the last > > case we should at least give the name (and pid?) of one application so > > that you can make progress on unmount by killing that. > > Right, I definitely think we want the dialog to look something like this > > +---+ > | Cannot unmount "public_html @ p.fd.o", the following | > | applications are still using it | > | | > | [icon] GEdit - Secret Stuff.txt[kill] | > | [icon] GEdit - My Diary.txt[kill] | > | [icon] Tomboy [kill] | >
Re: [gfvs] cdda backend
On Wed, 2007-12-19 at 16:43 -0500, David Zeuthen wrote: > Hi again, > > Almost more questions than answers this time, sorry. Also no patch > either since I wanted to hear your thoughts before doing the work. > it's not supported in the API yet because that > situation can never happen for the use I wrote it for (cdda:// backend). I added the unmount flags to all unmount and eject calls and the remount operation to GMount. All users are fixed up, but nothing implements these yet. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington: > Then the following default implementations: > > - all four of the new functions have default implementations that > invoke the current size_request and use it for both min and natural > size; so unmodified widgets still support the new interface So you suggest, that GtkWidget implements GtkExtendedLayout? Ciao, Mathias -- Mathias Hasselmann <[EMAIL PROTECTED]> Openismus GmbH: http://www.openismus.com/ Personal Site: http://taschenorakel.de/ signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gfvs] cdda backend
On Thu, 2007-12-20 at 12:54 +0100, Alexander Larsson wrote: > On Wed, 2007-12-19 at 16:43 -0500, David Zeuthen wrote: > > Hi again, > > > > Almost more questions than answers this time, sorry. Also no patch > > either since I wanted to hear your thoughts before doing the work. > > it's not supported in the API yet because that > > situation can never happen for the use I wrote it for (cdda:// backend). > > I added the unmount flags to all unmount and eject calls and the remount > operation to GMount. > > All users are fixed up, but nothing implements these yet. Great, thanks. I'll add this to the unix and hal backends. Cheers, David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gfvs] cdda backend
On Thu, 2007-12-20 at 11:57 +0100, Alexander Larsson wrote: > So, I guess the question is, in what way is it better to have > "public_html @ p.fd.o" be a volume than using a bookmark for this? I suppose either works; it was just an idea. The main advantage is that the icon for the volume wouldn't jump around (bookmarks IIRC are stored below a separator line in the file chooser and sidebar) if you double click it in the file chooser. I think bookmarks are more intended for files or folders? I don't know. > > gboolean (*request_adoption_of_orphan_mount) (GVolume *adopter, > >GMount *orphan); > > > > that each implementation can implement? Alternatively we can put this > > method on the GMount interface but that seems wrong since it's only > > something volume monitors would ever want to do. > > The volume monitor would recurse over all volumes and call this? > > Isn't it better to have something like: > > GMount * (*find_orphan_mount_for_adoption) (GVolumeMonitor *monitor, > GVolume *adopter) Actually with the proposal I had, the adoptor itself would iterate over all mounts and use it's own criteria of how to pick an orphan - it's probably in a better position to choose than the orphan's volume monitor? I mean, suppose we did "fav servers" as a GVolume stemming from a "fav servers" volume monitor; how would GDaemonVolumeMonitor know how to pick adopter? (OTOH, the "fav servers" volume monitor backend would have no problem picking the orphan; it would just compare the get_mount_root() from each GMount on the system with whatever preferences it relies on) > I really think you are overreacting a bit on this. For regular unix > mounts it is often the case that you get stuck with busy mounts, because > applications with cwd inside the mount keep it open, or due to a dnotify > watch. However, for gvfs mounts the only time something is busy is if > there is actually an ongoing operation like a file copy, loading a file > or something like that. This is far less likely to happen when you > unmount a volume, and its far easier to be aware of this (for instance > you'd have a copy file progress notification icon for the file copy, or > just loading a file in gedit). > > Furthermore, since we can make sure we can succeed 100% with a forced > unmount, having a blunt instrument like killing an application that is > doing an operation on the volume seems like the wrong thing to do. I > can't think of any reason you'd want to do this instead of forcefully > unmounting and have the apps doing the operation get an i/o error. > > So, adding this chunk of lowlevel weird stuff (where you have to expose > nonportable things like pids, etc) to the supported portable highlevel > API for this very rare case that we can handle well with a force unmount > anyway seems like a bad idea. > > Now, maybe you're thinking of using this for unmounting in the hal > backend were we're talking about unmounting unix filesystems, which do > not support a nice force unmount and are more likely to be busy. Yes, > this is more of a problem, but do we really need to expose the > implementation of lsof in the highlevel API. Isn't it better to just > encapsulate the whole thing (dialog/widget + getting the data for it) in > a single call. Sure, we can do that as well (putting the calls to lsof(8) into the code creating the dialog). It just seems like a waste to not abstract this stuff out. There's GPid in glib already so am not sure why this isn't portable (list_open_files() would be allowed to error out with G_IO_ERROR_NOT_SUPPORTED of course). Btw, I wouldn't be so sure about busy mounts; what if you keep you media collection on a networked share? People are working on moving people's documents and media off the client and on to hosted storage services; it seems we'll be getting more of this. (And you can cwd into ~/.gvfs too but I agree that is not so common). > > > If you want to extend this goal, you need to describe exactly what is > the target of the new API. What should you be able to do with it, and > what not. Then we can discuss how this is best achieved. Sure, in addition from the gio volume monitoring just being a utility library to be used by the file manager and file chooser, I'd like it to be useful for other things. First is auto mounters like e.g. gnome-volume-manager. This is necessary because some file systems for devices like cameras and audio cd's are not handled by hal (e.g. cdda:// and gphoto2://). So the auto mounter needs to at least pay attention to the volume monitor to mount a gphoto2 camera and a cdda disc. The other thing the auto mounter does is prompt the user for what application to run when media with well-known content is inserted (cf. this http://people.freedesktop.org/~david/g-v-m-prefs.png ). Hence you need to have an idea of what could be on the media - similar to the similar to g_mount_guess_c
Using GLX_EXT_texture_from_pixmap for redirected rendering of widgets/windows.
Greetings xorg/gtk+-crowd! I finally got that "gtk+-widgets _ontop_ of a GL-context" working and would like to get some input from anybody interested in the topic. Apart from toolkit-level input-redirection not working, which is likely another big chunk of work to design and implement, I am mainly interested in solving any possible GLXFBConfig-selection issues, people might run into. Sofar I've only successfully tested it under metacity/compiz on a GeForce-card and still battle to get it working on an i965. On the side of rendering-performance I feel that I am still missing some optimization in the way I do draw the widgets on quads, because of a slight CPU-hit I experience here (mapping such a small texture at a refresh of 20Hz or 60Hz should not be noticeable at all). The general approach used to get it going, is to stuff the widget(s), which are loaded in from a glade-description, in a GtkEventBox, use gdk_window_set_composited() on the GtkEventBox to redirect it to an offscreen pixmap, select a matching GLXFBConfig derived from the top-level GtkWindow and use GLX_EXT_texture_from_pixmap to finally obtain a GL-texture from the widgets pixmap. All this is then drawn with GL right into the top-level GtkWindow. A screenshot of the examples running... http://macslow.thepimp.net/shots/gtk-examples-1.png The source to the examples can be grabbed with... bzr branch http://bazaar.launchpad.net/~macslow/gtk-offscreen-1/trunk gtk-offscreen-1 bzr branch http://bazaar.launchpad.net/~macslow/gtk-gl-offscreen-1/trunk gtk-gl-offscreen-1 bzr branch http://bazaar.launchpad.net/~macslow/gtk-gl-offscreen-2/trunk gtk-gl-offscreen-2 bzr branch http://bazaar.launchpad.net/~macslow/gtk-gl-rgba-1/trunk gtk-gl-rgba-1 Thanks in advance! Best regards... Mirco "MacSlow" Müller ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gfvs] cdda backend
On Thu, 2007-12-20 at 10:45 -0500, David Zeuthen wrote: > On Thu, 2007-12-20 at 11:57 +0100, Alexander Larsson wrote: > > So, I guess the question is, in what way is it better to have > > "public_html @ p.fd.o" be a volume than using a bookmark for this? > > I suppose either works; it was just an idea. The main advantage is that > the icon for the volume wouldn't jump around (bookmarks IIRC are stored > below a separator line in the file chooser and sidebar) if you double > click it in the file chooser. I think bookmarks are more intended for > files or folders? I don't know. Bookmarks are for folders (you get default bookmarks for things like the photos folder, etc). I'm not saying I know what is best, just that its not obvious what the best route is. > > > gboolean (*request_adoption_of_orphan_mount) (GVolume *adopter, > > >GMount *orphan); > > > > > > that each implementation can implement? Alternatively we can put this > > > method on the GMount interface but that seems wrong since it's only > > > something volume monitors would ever want to do. > > > > The volume monitor would recurse over all volumes and call this? > > > > Isn't it better to have something like: > > > > GMount * (*find_orphan_mount_for_adoption) (GVolumeMonitor *monitor, > > GVolume *adopter) > > Actually with the proposal I had, the adoptor itself would iterate over > all mounts and use it's own criteria of how to pick an orphan - it's > probably in a better position to choose than the orphan's volume > monitor? I mean, suppose we did "fav servers" as a GVolume stemming from > a "fav servers" volume monitor; how would GDaemonVolumeMonitor know how > to pick adopter? Hmm, i guess. But how can the fav server volume monitor iterate over all mounts? It doesn't see other volume monitors. > Sure, we can do that as well (putting the calls to lsof(8) into the code > creating the dialog). It just seems like a waste to not abstract this > stuff out. There's GPid in glib already so am not sure why this isn't > portable (list_open_files() would be allowed to error out with > G_IO_ERROR_NOT_SUPPORTED of course). Well, any time you expose an abstraction like this you limit both how the backend can work, and what details you can show in the dialog. Plus you add more stuff to the API that most people really don't need. What would list_open_files() returns? A list of a new kind of GObject? > Btw, I wouldn't be so sure about busy mounts; what if you keep you > media collection on a networked share? People are working on moving > people's documents and media off the client and on to hosted storage > services; it seems we'll be getting more of this. (And you can cwd into > ~/.gvfs too but I agree that is not so common). You mean while the player plays a media file it would be busy. I guess thats not to uncommon. pwds in ~/.gvfs don't keep the GVfs busy, as ~/.gvfs is just a single mount. > The rationale for the patch is to > > - define "what could be on the media" means (x-content/*) > - unify all sniffing code into a single place >- likely pluggable so 3rd party libs (like libipoddevice), that > actually handle dealing with the device in question, can > participate > - involves name and icon selection too > - encourage people to use (and write) gvfs backends instead of using >Linux/UNIX-only libraries in their apps thus rendering non-portable > > Because, right now, it's a mess and every app (including the auto > mounter) does their own thing. The result, as you can see from the > screenshots, is that things not only look different, the names are > different too. (and ideally, there would be a stock "select_media" > dialog where you pass one or more x-content/* identifiers.) Sounds like a good reason. > Of course, it's fine if this is not a goal for gio but then volume > monitor API of gio isn't really useful outside the file manager and the > file chooser and should perhaps be private API instead. I just want to make sure we don't add something that apps can't use that we have to support forever. We need to make sure all APIs are right, sane and useful. I'm tired of maintaining big-bag-of-crap libraries... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [gfvs] cdda backend
On Thu, 2007-12-20 at 17:10 +0100, Alexander Larsson wrote: > Hmm, i guess. But how can the fav server volume monitor iterate over all > mounts? It doesn't see other volume monitors. It would use the union monitor through the standard volume monitor API? > What would list_open_files() returns? A list of a new kind of GObject? Yeah, I think. > > Because, right now, it's a mess and every app (including the auto > > mounter) does their own thing. The result, as you can see from the > > screenshots, is that things not only look different, the names are > > different too. (and ideally, there would be a stock "select_media" > > dialog where you pass one or more x-content/* identifiers.) > > Sounds like a good reason. I'll try to iterate over the patch. Thanks for considering! > > Of course, it's fine if this is not a goal for gio but then volume > > monitor API of gio isn't really useful outside the file manager and the > > file chooser and should perhaps be private API instead. > > I just want to make sure we don't add something that apps can't use that > we have to support forever. We need to make sure all APIs are right, > sane and useful. I'm tired of maintaining big-bag-of-crap libraries... Yeah. I'll try to be preemptive and raise the idea of x-content/* on the xdg lists. That's one thing we want standardized... David ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Extended Layout Summary
Hi,
Mathias Hasselmann wrote:
> Am Dienstag, den 20.11.2007, 15:41 -0500 schrieb Havoc Pennington:
>
>> Then the following default implementations:
>>
>> - all four of the new functions have default implementations that
>> invoke the current size_request and use it for both min and natural
>> size; so unmodified widgets still support the new interface
>
> So you suggest, that GtkWidget implements GtkExtendedLayout?
Several factors I can think of here.
First when implementing each container, it would be nice to avoid:
if (is_extended_layout(child)) {
use new request API
} else {
use old size request API
}
One solution would be that GtkWidget automatically implements extended
layout in terms of size request. Another solution would be just a
convenience function that does the above.
I'm guessing your patch already had a solution to this, I don't remember
what it was.
Two, when implementing a widget, it would be good to avoid writing both
the old size request and the new extended layout. So, one way to do that
is that in GtkWidget there's a default implementation of size request
that invokes extended layout. This may require GtkWidget to implement
extended layout, or maybe the default impl of size request could do
GTK_IS_EXTENDED_LAYOUT(), that might be fine too. Then GtkWidget would
not have to implement extended layout.
Third, since implementing an interface requires extra boilerplate
GObject stuff, it would be convenient for authors of a custom widget if
GtkWidget already did the boilerplate for them. Since for newly-written
custom widgets, the recommendation would be to always support extended
layout.
Those are the factors I can think of. I might be wrong about them, or
there may be other factors that are also important and that lead to the
opposite conclusion.
Havoc
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Test reports and commit policies
Hey All. A quick update on the unit test reports, a script for test report generation has now been comitted to GLib and will be used to generate HTML reports for the test report rules test-report, perf-report and full-report. The reports should render in all browsers and support colorization and collapsed/popup details for CSS and javascript enabled browsers. Example reports generated from today's SVN are provided here: http://people.imendio.com/timj/examples/glib-full-report.html http://people.imendio.com/timj/examples/gtk+-full-report.html Percentages are reported for the amount of tests that failed or succeeded, e.g. gtk+/tests/.libs/lt-objecttests is reported with a result of 80.39%, because ca. 20% of our automated widget property tests fail (generate some warnings or crash Gtk+, volounteers to look into those cases highly needed). It'd be nice if someone in the community could set up a build machine for jhbuild/modulesets/gtk.modules that builds, runs test-report, perf-report and full-report and uploads the resulting test-report-html, perf-report.html and full-report.html from GLib and Gtk+ to some public location. About commit policies, now that we have a test framework in place that distinguishes between slow (make full-report) and fast (make check) tests, and allows subcomponent related tests (e.g. make check -C gtk+/gtk/), it'd be nice to actually make ue of it. So i'd like to suggest that we establish some basic commit/test policies, e.g.: 1) Before committing changes in glib/ or gtk+/, a developer needs to ensure that make check -C glib/ (or make check -C gtk+/) passes. 2) For major changes (adding new components, changing lots of files, changing Makefiles, etc.), developers should run make full-report on the whole module and investigate the failing test cases before committing. The exact rules/process is open for discussion of course, the above is meant as some initial food for thought. Please discuss! ;-) --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GLib Testframework API
On Tue, 18 Dec 2007, Johan Dahlin wrote:
> Sorry for being late in the game for comments, but here we go.
>
> In general this api differs slightly from JUnit/python, which has the
> following (main) methods:
>
> assertEqual
> assertNotEqual
> assertTrue
> assertFalse
> assertRaises
yeah, i've looked at the JUnit API when designig the glib test API, but
didn't find those assertions to be too applicable. e.g. there's not too
much difference in:
g_assert (condition == TRUE);
g_assert_true (condition);
g_assert (condition == FALSE);
g_assert_fail (condition); // suggested by Behdad
if people strongly feel those need to be added we can do that, i just
fail to see a significant benefit.
> Perhaps the term "equals" could be used instead of "cmp".
the existing API uses "cmp" because it implements memcmp(3) result semantics,
i.e. -1,0,+1 instead of eaqulity ('==') semantics.
for int/hex/float, this should obviously make sense, and for strings it
mimicks the most common comparison API, i.e. strcmp().
> I haven't looked in detail at the trap api, but having something similar to
> assertRaises for g_error & friends would be a good thing.
hm, i'd say the closest thing to assertRaises in glib *is* g_error().
maybe you meant GError? that might be useful to have, patches welcome ;)
> g_assert_cmpstr, accepts a comparison operator, while this makes sense for
> comparing floats and integers I don't think it should be included in the api
> for strings.
> Basically, the only thing you want to check if is a string is equal to
> another or not, so perhaps it could be replaced with:
>
> g_assert_equals_str
> g_assert_not_equals_str
>
> Or do you see a use case for using other operators besides == and != ?
sure, if you use strcmp() to sort a list of strings, you'd use
g_assert_cmpstr() to test the invariants. and as i wrote above, offering
'cmp' here instead of 'equals' is what C coders are most used to anyway
(and consistent with the other g_assert_cmp*() variants).
keep in mind that the g_assert_*() family is about convenience anyway,
everyone is free to fallback to g_assert() or if(...)g_error() for his
checks.
a remaining issue i see with g_assert_cmpstr() however is that we should
probably also have g_assert_casecmpstr(), similar to g_strcasecmp().
> Johan
---
ciaoTJ
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [directfb-dev] Expose event for DirectFb
Sreenivas Chowdary wrote: > As far as i know there is no expose equivalent event on DirectFb. > There are events for DirectFbWindow like window got focus, keypress, > button press, mouse cursor motion etc > We also faced same issue about expose event when porting firefox. DirectFB does only know about the top level windows and never changes their content on its own. So there's no need for expose events sent by DirectFB. A toolkit needs to manage child windows itself and do whatever is needed to redraw within the top level window surface. Sending expose events, queueing updates or just calling its drawing functions is up to the toolkit. I don't have a complete overview of all expose, redraw, paint, update, queue stuff of GTK+/GDK and the backends. But the code in GDK-DirectFB might still need some updates, either for fixing issues or to benefit from improvements in the GDK layer. -- Best regards, Denis Oliver Kropp .--. | DirectFB - Hardware accelerated graphics | | http://www.directfb.org/ | "--" ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkFileChooser and GVFS backend
> we need a plan for how to handle the gvfs filechooser backend for 2.22. > I think it will be best to put it in libgnomeui, next to (or > replacing) the gnome-vfs backend thats already there. > Seems we never get rid of this deprecated library. But its probadly the best way at this time. > After 2.22 we can look at moving it over to gtk itself, or doing > something > better. > I really hope this goes in gtk in next release of gtk (so we hopefully can kill libgnome* :) / Mikael Hermansson ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkFileChooser and GVFS backend
On Thu, 2007-12-20 at 18:59 +0100, Mikael Hermansson wrote: > > we need a plan for how to handle the gvfs filechooser backend for > 2.22. > > I think it will be best to put it in libgnomeui, next to (or > > replacing) the gnome-vfs backend thats already there. > > > > Seems we never get rid of this deprecated library. not until we break API; until that time, we still have to provide libgnome*. > But its probadly the best way at this time. it's also the only way, at the moment. :-) ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: [directfb-dev] Expose event for DirectFb
If you have child widgets that use subsurfaces and they overlap then you have a expose type issue. For top level surfaces you can simulate and expose if you track the first time the window was "made visible". This correlates with modern X11 servers that use buffered windows and only send expose on the first show and on resize for the window. Overlapping lightweight widgets forces the toolkit to run its own paint manager generally using the painter algorithm. I'm working on a new approach for DirectFB and the surface pools are a HUGE improvement since they lay the ground works for building composite managers and window manager as two different concepts. I'm planning on meeting with Denis face to face in January to go over what I've done to date and directfb. At the high level is to remove the current windowmanager from DirectFB and replace it with a composite manager thats similar but deals with the new surface pools. Then we can build Window Manager suited for different toolkits on top. For desktop applications the final result would be similar to the current rootless DirectFB X11 server and concept. It probably helps the define the various core pieces. Graphics Core: Manages Graphics Card and multi process access. Provides accelerated drawing surfaces and graphics primitives. Input drivers. A composite manager: Manages a Z ordered tree of surfaces generally rooted on a screen and assigns certain surfaces as belonging to different processes. It also does at least basic routing of events to different processes generally just the window manager. Window Manager: Special client that should be allowed to draw window decorations as the top level surfaces are composited. Does the actual mapping of input events to windows. And defines what surface or parts of a surface can be drawn on by regular applications. X11 does this with a complex clip. DirectFB provides a shared surface. X11 window managers are implemented by catching requests to create a top level and reparenting. Since child windows are considered to be widgets is directfb X11 is a bastard composite, window and partial widget manager. The current DirectFB Window Manager is really a composite manager that shares the top level surfaces. The two concepts need to be split. So you can see that what needs to happen on the directfb side is we need to decouple the compositing of top level surfaces from the "window manager". In my own work I've introduced the concept of canvas which is just a Z tree of rectangular regions. This canvas's can use the parent surface or provide their own. Painting is down with two methods. Paint and composite that are callbacks from the Composite manager. Paint is used to either draw on the parents surface if you don't have a buffer or into your buffer. Next composite is called which blits the buffer to the parent. This is just a library and now the Window Manager becomes a app that uses the toolkit to create widgets called windows. Applications can use the same canvas toolkit to create widgets. And finally this system is designed with a declarative canvas in mind so Window managers can just send the direct drawing code to the canvas manager so it can draw in the main composite loop. Now back to Expose. Its really just a notification that a region is dirty and needs painting so its better to call expose a paint event. So at least for my approach you will get "paint" events if needed from the canvas manager that can be sent to the application. So to finish the new design I want to see is. DirectFB -> surface pool and top level composite manager. Window Manager outside of DirectFB. In my cases I've split the concept into a canvas toolkit used by both the wm and apps. Finally we need to reintroduce DirectFB window's and surfaces and potentially a canvas manager for the API. But the provider of the window interface is a pure module with the current api as a compatibility module. And finally with all this said what I would like to see is that toolkits like DirectFB request the style of window manager they would like to use its up to the developer of directfb Window managers to provide the interface if requested. This way we can explore going to a more complex "beyond windows" desktop application interface and still support legacy apps based on X11 questionable drawing model if needed. Thus you see why I want a rootless X server like concept so we don't have X11 cruft contaminating the core of directfb just to support legacy toolkits. On Dec 20, 2007 9:11 AM, Denis Oliver Kropp <[EMAIL PROTECTED]> wrote: > Sreenivas Chowdary wrote: > > As far as i know there is no expose equivalent event on DirectFb. > > There are events for DirectFbWindow like window got focus, keypress, > > button press, mouse cursor motion etc > > We also faced same issue about expose event when porting firefox. > > DirectFB does only know about the top level windows and never changes > their content on its own. So there's no
Re: [gfvs] cdda backend
On Dec 20, 2007 11:36 AM, David Zeuthen <[EMAIL PROTECTED]> wrote: > > I'll try to iterate over the patch. Thanks for considering! > > > > Of course, it's fine if this is not a goal for gio but then volume > > > monitor API of gio isn't really useful outside the file manager and the > > > file chooser and should perhaps be private API instead. > > > > I just want to make sure we don't add something that apps can't use that > > we have to support forever. We need to make sure all APIs are right, > > sane and useful. I'm tired of maintaining big-bag-of-crap libraries... > > Yeah. I'll try to be preemptive and raise the idea of x-content/* on the > xdg lists. That's one thing we want standardized... > Before thinking of standardizing, I'd propose to start a discussion with the authors of the apps that you have talked so much about here: f-spot, rhythmbox, etc. If they all think this is cool, you are onto something and may proceed to standardization... ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GLib 2.15.0 released
GLib 2.15.0 is now available for download at: ftp://ftp.gtk.org/pub/gtk/2.15/ http://ftp.gnome.org/pub/GNOME/sources/glib/2.15/ glib-2.15.0.tar.bz2 md5sum: 52536475a3f301842cf3448f19af094c glib-2.15.0.tar.gz md5sum: 8348f77a5aacf6382ee816f986ae7820 This is the first development release leading up to GLib 2.16. Notes: * This is unstable development release. While it has had a bit of testing, there are certainly plenty of bugs remaining to be found. This release should not be used in production. * Installing this version will overwrite your existing copy of GLib 2.14. If you have problems, you'll need to reinstall GLib 2.14. * GLib 2.16 will be source and binary compatible with the GLib 2.14 series; however, the new API additions in GLib 2.15.0 are not yet finalized, so there may be incompatibilities between this release and the final 2.16 release. In particular GIO may still see API changes. * The new GIO component in this release is accompanied by a new module, GVFS, that contains various backend implementations. GIO can be used without GVFS, but then it only supports local filesystems. * Bugs should be reported to http://bugzilla.gnome.org. About GLib == GLib is the low-level core library that forms the basis for projects such as GTK+ and GNOME. It provides data structure handling for C, portability wrappers, and interfaces for such runtime functionality as an event loop, threads, dynamic loading, and an object system. More information about GLib is available at: http://www.gtk.org/ An installation guide for the GTK+ libraries, including GLib, can be found at: http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html Overview of Changes from GLib 2.14.x to GLib 2.15.0 === Major new features: * GIO: a VFS API, designed to replace GnomeVFS. The GIO implementation in GLib has support for local filesystems. The new, separate gvfs module contains various backend implementations (cifs, ftp, sftp, http, ...) * GChecksum: provides various hash algorithms, such as MD5, SHA-1 and SHA-256 * GTest: a test framework Smaller additions: * GHash: - GHash has iterators, as an alternative to g_hash_table_foreach * GMarkup: - g_markup_parse_context_get_element_stack: New function to get the stack of open elements - G_MARKUP_PREFIX_ERROR_POSITION: New flag to improve error reporting - g_markup_collect_attributes: Convenience function for handling attributes * GKeyFile: - Functions that take a GError now return a boolean to indicate success, instead of void - Various performance improvements * GAsyncQueue: - g_async_queue_new_full: new function that allows to specify a free function for leftover elements * GError: - g_prefix_error and g_propagate_prefixed_error: New functions to ease error propagation * Internationalization: - C_: A new 2-argument variant of the Q_() macro - Use native character set conversion API on Windows * GLib builds with automake 1.10 * Bugs fixed: 455725 specific combination of g_utf8_strlen and g_pattern_match... 467537 g_convert_with_iconv() not resetting iconv() state correc... 497033 Commandline option parser should warn about missing optio... 504527 gchecksum: Conditional jump or move depends on uninitiali... 445362 Non-numeric local labels in gatomic.c are causing linker ... 482313 gregex: no way to tell why compilation failed 317775 main loops continues to run after g_main_loop_quit() has ... 418778 Insufficient pkg-config version requirement 436293 g_option_context_new() doc should mention that the string... 466557 glib-mkenums shifts ARGV[0] to undefined 468882 GKeyFile doesn't accept "True" as a true boolean value 469551 application --help messages are garbaged on none UTF-8 lo... 479724 Memory leak upon calling "g_main_loop_run" in the seconda... 490061 outptrs uninitialized after g_parse_long_long 490637 gobject documentation patch 495294 glib-genmarshal prints warnings but returns 0 496046 option to prefix location of errors for GMarkup 498113 tests/regex-test fails on 64bit environment 500506 Fails to build on OSX 10.4 500638 gkeyfile speedup ... 500875 Make check fails as there is no "test" target for "build"... 502511 g_assert_cmphex prints invalid message 502927 g_array_index triggers cast aligment warning 503029 g_time_val_from_iso8601 parse non-ISO8601 dates 503222 Need context to translate 503420 gkeyfile leaks a hash table 503470 Fix build when builddir != srcdir 504227 Inverse variant for g_test_trap_assert_stdout, g_test_tra... 71704 file include order 491957 Misprint in the specification of the interface "g_main_co... 491959 Misprint in description of the structure "GThreadPool" 491965 Mistype in the specification of the function "g_hook_list... 491966 Misprint in the specification of the interface "g_main_co... 491968 The documentation
