Re: new stock icons
On Mon, 2007-04-02 at 19:40 +0200, Jakub Steiner wrote: > I propose a replacement of the current gtk stock icons with newly > created artwork[1]. The set uses the exact same metaphors so it's > unlikely to cause any trouble with applications using the icons in a > slightly changed context. It has been drawn from scratch to be > distributable under the GNU LGPL license. I support the proposal, especially as it comes from the guys who're doing all the actual artwork [*]. You're in a good position to judge the consequences. Personally, I think that a few non-stock icons looking out of place in a transition period is acceptable. It would be nice if we could evaluate any problematic app icons as candidates for future stock inclusion. [*] I'm assuming you have the GNOME artists behind you in this. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Thu, 2007-04-19 at 12:33 -0500, Brandon Casey wrote: > I am posting to suggest that glib has crossed a threshold > of size and functionality and that users would benefit from > a splitting of the library into two or more separate libraries. > > [...] > > The growth in size and in dependencies is making it difficult > to compile glib on non linux platforms. It is regrettable > that some software projects have to avoid glib because of this, > and then re-invent the wheel when glib has a well tested, stable > and secure version. I think we need some specifics: - What exactly is not portable? - On which non-linux platforms is it failing? - What dependencies are problematic? - Which projects are known to be suffering as a result? While I agree that the GLib maintainers need to be prudent about what goes into GLib, almost all of what's currently in there seems like pretty basic stuff to me. I think the definition of "basic functionality" has expanded over time, though, and C needs more and more help to keep up with functionality that's implicit in other, more modern languages. Also consider the fact that GLib already consists of multiple libraries (GLib, GObject, GThread, and possibly a future GVFS). -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: is glib too bloated?
On Mon, 2007-04-23 at 17:03 +0100, Peter Clifton wrote: > I've found myself wanting GObject derived GList. The idea is to have a > "list of things with some GType", and make the API which modifies that > list emit "changed", "deleted", "inserted" signals, etc. I coded a > GObject derived class to do most of this. > > One thing missing with GList is type safety of course, but if you want, > you can add run-time type safety with a class around it. That sounds a bit like you want an MVC data model in GLib. For instance, we could move GtkTreeModel and its associated model parts down. I've been wanting that for a while now, personally. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some comments about GVFS
On Mon, 2007-05-07 at 09:24 +0200, Alexander Larsson wrote: > On Fri, 2007-05-04 at 17:52 +0200, Benjamin Otte wrote: > > Yeah, I missed those implementations as I was only grepping for > > GMainContext which you don't use. > > I think it's a good idea to make the main context customizable so gvfs > > can be used from other threads. > The api used to have this, but there was a lot of overhead code carrying > this around and adding it to the parameter list of all functions, and I > thought there would be very very few people using it, so i killed it. > Maybe we should discuss reverting that decision... In Flow, I keep a GMainContext associated with each GThread. The API user can set his own GMainContext for each thread, but for simplicity it can only be set once, before any other Flow calls are made in that thread. I find that this allows for a lot of flexibility without adding much code complexity at all: 1) The default GMainContext for the main thread is the default GLib GMainContext. This allows sync operations to spin the main loop (so if you have a program that lends itself to that design, you can process redraws and UI operations while in a sync I/O call). 2) If you want hard blocking sync I/O calls, just set a different GMainContext for the thread, and don't use it for anything else. 3) You can get at the GMainContexts used in subthreads, so you can e.g. add your own timeouts or whatever to those. And the best thing is, you never have to pass the GMainContexts around. The context-per-thread management API is tiny: http://svn.gnome.org/viewcvs/flow/trunk/flow/flow-context-mgmt.h?revision=154&view=markup The only thing that can cause trouble is that in Flow code proper, I have to be careful to use flow_get_main_context_for_current_thread () instead of g_main_context_default (). Ditto for idle and timeout convenience functions. But I consider that minimal cost. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some comments about GVFS
On Tue, 2007-05-08 at 09:30 +0200, Alexander Larsson wrote: > On Mon, 2007-05-07 at 14:08 -0500, Hans Petter Jansson wrote: > > In Flow, I keep a GMainContext associated with each GThread. The API > > user can set his own GMainContext for each thread, but for simplicity it > > can only be set once, before any other Flow calls are made in that > > thread. > So, an async operation inherits the main context from the thread that > started it. Its nice that you don't have to fill up the API with context > arguments, but it also seems to make it a bit more complicated to handle > multiple contexts. For instance, you can't have one thread starting > async operations that run on multiple context. But perhaps this is not > so important? What do users of multiple contexts need? Being able to provide a different main context on each call is extremely flexible, but in the end I doubt it is necessary in the majority of apps, and as you pointed out, it clutters the code. The main reason I have the main-context-per-thread is that a Flow pipeline won't run without a main context - for instance, elements can limit flow rate by installing a timeout and resuming when it fires, or otherwise generate timed events. And applications will definitely want to run pipelines in threads. I'm used to three main design patterns: 1) Everything in one thread with sync I/O blocking the UI. Simple code but unacceptable performance. 2) Everything in one thread with async I/O using callbacks. Fine for simple protocols or if you prefer an explicit state machine. 3) Doing synchronous I/O operations in one or more subthreads that talk to the main thread using asynchronous messages queues. This is nice for complex protocol implementations, because synchronous code is easier to understand and maintain. All of the above can be done with I/O dispatched in a single GMainContext per thread. 1) is a special case where you could have one GMainContext for the UI and another for the I/O. That said, it'd be interesting to know if anyone runs multiple main contexts in a single thread and needs to dispatch I/O events in more than one of those. It sounds rather contrived to me... > > I find that this allows for a lot of flexibility without adding much > > code complexity at all: > > > > 1) The default GMainContext for the main thread is the default GLib > > GMainContext. This allows sync operations to spin the main loop (so if > > you have a program that lends itself to that design, you can process > > redraws and UI operations while in a sync I/O call). > Danger will robinson! This sounds like a recipe for disaster. Sync calls > calling back into the mainloop can easily cause reentrancy, and we're > back in bonobo hell again. I.E. call any flow function, and you could > reenter (via a mainloop callback) into any random code in the app which > could modify the state of the code that was calling flow. (And if that > state is in a partially changed state things can go very bad.) > > Its also very problematic wrt locking. We have the same problem with > authentication callbacks in gnome-vfs. These are called back from any > sync operation when authentication is needed, and often requires UI to > finish, and thus a mainloop. However, since it is doing UI it needs to > take the gdk lock, but that deadlocks if the gdk lock was taken when the > sync call was called. In the case of flow, what if you get an idle > callback inside a sync call, and the idle callback (correctly) takes the > gdk lock... I'm aware of the dangers - when I worked on Evolution, this caused plenty of pain. However, it's useful in very simple apps where you have e.g. a "Sync" or "Connect" button which desensitizes most of the UI while the operation is in progress, only updating a progress bar or allowing the user to hit "Cancel". That's what I meant by a "program that lends itself to that design" above :) So I dunno. Maybe it's too seductive and should be eliminated as an option. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Some comments about GVFS
On Tue, 2007-05-08 at 10:57 +0200, Alexander Larsson wrote: > On Tue, 2007-05-08 at 03:33 -0500, Hans Petter Jansson wrote: > > I'm aware of the dangers - when I worked on Evolution, this caused > > plenty of pain. > > > > However, it's useful in very simple apps where you have e.g. a "Sync" or > > "Connect" button which desensitizes most of the UI while the operation > > is in progress, only updating a progress bar or allowing the user to hit > > "Cancel". That's what I meant by a "program that lends itself to that > > design" above :) > > > > So I dunno. Maybe it's too seductive and should be eliminated as an > > option. > Avoiding this problem is one of the primary reasons of going from a > stateless model (where you can get auth callbacks anytime) to a > statefull model (auth only on mount). However, that problem in gnome-vfs > happens for *all* apps, not only those that "lend itself to that > design", so its a larger problem there. Agree. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk: hide window when minimized
On Tue, 2007-05-15 at 12:55 +0100, Emmanuele Bassi wrote: > On Tue, 2007-05-15 at 13:51 +0200, bronson wrote: > > could anyone tell me how can I hide window, when user minimizes it? > > I tried to handle signal 'window-state-event', but when in that method i > > hide window, > > strange things happen - window hides, and then shows up again and it > > never ends. > why would you want to hide a minimised window, which should already be > hidden by your window manager? > > and, most of all, you should really ask on gtk-app-devel-list - this > list is for developing gtk+, non *with* gtk+. Sounds like he wants a minimize-to-tray behaviour, which is common on Windows. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: On Emblems
On Thu, 2008-08-21 at 01:32 +0200, Clemens Buss wrote: > Ok, if GEmblemableIcon is great english, I don't know either ;-). As long as the accompanying documentation displays excellent English, I must say I don't care that "emblemable" represents incorrect use of aforementioned language :) Of course, if anyone can think of a better approach that won't cause confusion, that would be great. None of the native speakers I've asked came up with anything, though. Anyway. Not something I'd block on. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal for GTK+ advanced formatted entry and spinner API
On Tue, 2005-10-11 at 09:51 +0200, Itai Bar-Haim wrote: > I would like to propose my idea for Format-Elements, that will be used > to control GtkEntry and GtkSpinButton. > The idea is to allow organized, element-based formatting of data > displayed textually. > > [...] Interesting idea, but I'd much rather have GtkEntry use GtkTextBuffer and its formatting features somehow. That would also allow for inserting images and such, just like in GtkTextView, and would add less specialized API to GtkEntry and GtkSpinButton (which are supposed to be simple interfaces). I don't think something like this belongs there. -- Hans Petter Jansson | <[EMAIL PROTECTED]> Novell, Inc. Hacker | http://hp.cl.no/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Plans for gnome-vfs replacement
First off, thanks for starting this debate. It looks like gnome-vfs is in for an awesome overhaul. Some comments on streams below. On Mon, 2006-09-18 at 18:12 +0200, Alexander Larsson wrote: > I've been doing some initial sketching of the glib API, and I've > started by introducing base GInputStream and GOutputStream similar to > the stream objects in Java and .Net. These have async i/o support and > will make the API for reading and writing files nicer and more > modern. There is also a GSeekable interface that streams can > optionally implement if they support seeking. We may have a lot to gain from thinking about what we need in the low and intermediate level of the I/O stack now that we're discussing a clean-slate implementation. In addition to VFS, these should facilitate network protocols that don't map to file system operations - for instance, protocols for instant messaging, collaboration and games. Due to the need for asynchronous - and often multiple levels of - tokenization and events, this type of application quickly becomes a mess of callbacks into a complicated state machine. I'm thinking an element-based approach on the low-level end, similar to but simpler than GStreamer's, might alleviate this problem. It would make complicated stream code clearer and more reusable because there's an agreed-upon way to split tasks into multiple state machines (encryption, compression, flow rate limitation, tokenization, parsing, etc). You could also easily insert a "debug element" into a stream to divert an ASCII dump to a second stream for inspection - much nicer than lacing a monolithic I/O loop with g_print()s. Tokens and events could be represented by GObjects inlined in the stream. Of course, not all applications need such functionality, but that's just a matter of wrapping this in a higher-level, more rigid API. Also, what's your thinking on supporting asynchronous DNS lookups, representing IP addresses, TCP/UDP sockets, etc? We currently don't have any clear platform solution for that. -- Hans Petter "...you cut a piece, and as you're taking it off of the fork the main piece of the filet may be floating up out of the plate, but you stab it with your fork and put it back down in, and if you do it carefully, the surface tension of the gravy will keep it in place." - Russell Schweickart ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Streams API [Was: Re: Plans for gnome-vfs replacement]
On Wed, 2006-09-20 at 10:07 +0200, Alexander Larsson wrote: > On Tue, 2006-09-19 at 16:24 -0400, Hans Petter Jansson wrote: > > Of course, not all applications need such functionality, but that's > > just a matter of wrapping this in a higher-level, more rigid API. > In my reading of code using gnome-vfs i haven't seen a single use of > anything like this. Could you perhaps describe some real-life examples > of how/where this would be used? Well, a peer-to-peer filesharing application is the most extreme example I can think of. Such programs typically need encryption, rate control, ad-hoc protocol implementations, lots of TCP and UDP sockets and in decentralized networks, routing facilities. Now, we don't need to provide all of this, especially not in glib, but having the basic building blocks there would be nice. Another example is instant messaging applications, which require encryption (typically an SSL layer), rate control (so pasted text can be sent slowly, lest you trigger the server's anti-flood filter) and ad-hoc protocols. In fact, I think Gaim is a good example of how the platform's lack of a good, low-level async I/O API leads to broken applications: Gaim (at least version 1.5, which I inspected) has UI that blocks on network I/O, poor error handling and convoluted protocol code. It also features an interesting approach to "async" DNS lookups: Fork a child process and do lookups there, using pipes to communicate with it. Unfortunately, pipe communication was done using blocking posix calls, so the end result was a main process that could still block on DNS lookups. Also, Evolution could use it. It's possible that we're talking past each other here, by the way. I was thinking of the streams API as lower-level than VFS, so not something you'd see a need for perusing gnome-vfs consumers. My mental image is: [posix] <- [Async I/O] <- [Streams] <- [VFS] > >From just reading your post, without deeper insight into what you mean I > would be hesitant to add something like that to glib. Its not clear that > applications need it, and its not clear the the solution we create is > good enough for the applications that need something like it (in fact, I > think its likely that such apps want to do their own thing). > > [...] I wasn't proposing it specifically for glib, at least not the element-based stream model. I thought that was still up in the air. I think we can revisit this later, as the next part is more important to me anyway: > > Also, what's your thinking on supporting asynchronous DNS lookups, > > representing IP addresses, TCP/UDP sockets, etc? We currently don't > > have any clear platform solution for that. > These are interesting questions, and some applications would surely > benefit from such code (although others will consider it bloat). I don't > want to intermix these questions with the vfs layer though. They are not > really strongly related, only TCP sockets are slightly related to > streams, and not really in a very interesting way (its just another > possible stream implementation). If you're going to keep implementations of network protocols in glib (which I assume you'd have to for some VFS modules), you'll have to implement this anyway. Why not make it available to applications? I'm making the assumption that you'll keep VFS modules in glib because you mentioned it would have "odd dependencies" earlier. -- Hans Petter "...you cut a piece, and as you're taking it off of the fork the main piece of the filet may be floating up out of the plate, but you stab it with your fork and put it back down in, and if you do it carefully, the surface tension of the gravy will keep it in place." - Russell Schweickart ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Plans for gnome-vfs replacement
On Mon, 2006-09-25 at 13:14 +0200, Alexander Larsson wrote: > On Mon, 2006-09-25 at 11:40 +0200, Tim Janik wrote: > > hm, in your initial proposal, you said that apps don't currently have > > control > > over whether they want to use/care about threading or not. so, are you > > planning for a way to use the GVFS API without threading under the hood? > > then, emulation of the above asny calls would be implemented in terms of > > IO handlers attached to the provided GMainContext *context? > Its an unfortunate fact of life that unix doesn't support asynchronous > I/O for local files. I.E. a select on a local file *always* returns that > it is readable, but it might still block when you call read() while > reading the data from the disk. So, unless the OS has a good > implementation of posix async i/o (which e.g. Linux doesn't) the only > way we can get true async local file i/o is using threads. > > The way I had planned this was to always use true async i/o when talking > to the vfs daemon via sockets (easy), but implement local async i/o > using threads. If glib threads are not initialized we'd just fall back > to doing blocking "async" calls. You could use AIO on Linux and the equivalent on BSD, if you think it's worth the effort. Flow will have an AIO-based implementation eventually. -- Hans Petter "...you cut a piece, and as you're taking it off of the fork the main piece of the filet may be floating up out of the plate, but you stab it with your fork and put it back down in, and if you do it carefully, the surface tension of the gravy will keep it in place." - Russell Schweickart ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Plans for gnome-vfs replacement
On Wed, 2006-09-27 at 09:06 +0200, Alexander Larsson wrote: > On Tue, 2006-09-26 at 19:01 -0400, Hans Petter Jansson wrote: > > On Mon, 2006-09-25 at 13:14 +0200, Alexander Larsson wrote: > > > The way I had planned this was to always use true async i/o when talking > > > to the vfs daemon via sockets (easy), but implement local async i/o > > > using threads. If glib threads are not initialized we'd just fall back > > > to doing blocking "async" calls. > > You could use AIO on Linux and the equivalent on BSD, if you think it's > > worth the effort. Flow will have an AIO-based implementation eventually. > Unfortuantely the linux support isn't good enough. I talked to some > kernel people, and it would seem this is still pretty much the status > wrt posix aio: > http://lwn.net/Articles/148755/ > > In particular, we would need fixes for at least restrictions 1, 5 and 7. I think restriction 1 is the most serious for us, but we can work around it if we: - Always manage our own FD life cycles (i.e. no user-provided FDs, which is a good idea for portability too). - Copy/move data into aligned buffers. I don't consider 5 and 7 blockers. We can work around 5 with no-op priorities (much as we do for threads) and 7 by keeping the state of canceled operations around until the operation completes. Then this can be fixed under the hood when the kernel gets its shit together. Of course, just using threads is a lot easier. The "generic Unix-like" implementation I wrote for Flow uses threads for file I/O. The AIO implementation will be a Linux-specific bonus, for when the more important stuff is done. -- Hans Petter "...you cut a piece, and as you're taking it off of the fork the main piece of the filet may be floating up out of the plate, but you stab it with your fork and put it back down in, and if you do it carefully, the surface tension of the gravy will keep it in place." - Russell Schweickart ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is GStringChunk still useful?
On Mon, 2006-11-06 at 12:46 -0500, Matthew Barnes wrote:
> There has been some recent discussion in evolution-hackers over the
> value of GStringChunk in GLib. Jeff provided a pretty good analysis of
> its pitfalls [1], leaving me to wonder whether its continued use is
> still encouraged.
>
> I'm posting to this list hoping to get comments from a broader audience.
> Is this a data-structure that is generally shunned, and can anything be
> done to improve it? Should some kind of disclaimer about when and how
> best to use it be added to the documentation?
>
> [1]
> http://mail.gnome.org/archives/evolution-hackers/2006-November/msg3.html
I seriously doubt that GStringChunk is useful, because the gain from
using non-aligned memory is lost if your strings don't fit the block
size (e.g. too long strings as described by Jeff, or even just the last
block not being completely filled). I'm in favor of obsoleting
GStringChunk.
However, I think there's a way to cater to the single use case for which
people would think about using GStringChunk: The case where you have a
long-lived struct with a lot of (unchanging) string pointers in it.
Let me illustrate with an example:
typedef struct
{
gchar *from;
gchar *to;
gchar *cc;
gchar *subject;
gchar *body;
}
Mail;
Mail *mail;
We could introduce a function:
g_pack_strings (&mail->from, &mail->to, &mail->cc, &mail->subject,
&mail->body, NULL);
Which would strlen() the strings, allocate a block which would fit the
strings perfectly, copy the strings into the block, free the original
strings and replace the passed-in pointers with the strings' new
locations in the block. The block could be freed thusly:
g_free_packed_strings (&mail->from, &mail->to, &mail->cc,
&mail->subject, &mail->body, NULL);
Since the first non-NULL pointer would point to the start of the block,
g_free_packed_strings() would just call g_free() on that and return.
I think we want what I describe above, or nothing at all.
--
Hans Petter
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is GStringChunk still useful?
On Mon, 2006-11-06 at 22:28 -0500, [EMAIL PROTECTED] wrote: > On Mon, Nov 06, 2006 at 08:55:49PM -0600, Hans Petter Jansson wrote: > > I seriously doubt that GStringChunk is useful, because the gain from > > using non-aligned memory is lost if your strings don't fit the block > > size (e.g. too long strings as described by Jeff, or even just the last > > block not being completely filled). I'm in favor of obsoleting > > GStringChunk. > If true, then you should be able to prove it, and nothing is preventing > GStringChunk from returning aligned memory. > > Are you guessing? As stated, it depends on the use case. > > We could introduce a function: > > g_pack_strings (&mail->from, &mail->to, &mail->cc, &mail->subject, > > &mail->body, NULL); > > > Which would strlen() the strings, allocate a block which would fit the > > strings perfectly, copy the strings into the block, free the original > > strings and replace the passed-in pointers with the strings' new > > locations in the block. The block could be freed thusly: > I suspect this would defeat the purpose of using it in the first place. > How is mail->from allocated? If using an allocate function, and then > re-packing, all you are saving is space. Not allocation time. Space is > probably irrelevant in most applications. Allocation time, especially > in a multi-threaded context with synchronization on the free memory > pools, is not irrelevant. That's why I said long-lived. If the data is allocated and kept around for a long time, the space saved is more important than the CPU time lost. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Is GStringChunk still useful?
On Tue, 2006-11-07 at 02:49 -0500, [EMAIL PROTECTED] wrote: > On Mon, Nov 06, 2006 at 09:30:17PM -0600, Hans Petter Jansson wrote: > > On Mon, 2006-11-06 at 22:28 -0500, [EMAIL PROTECTED] wrote: > > > On Mon, Nov 06, 2006 at 08:55:49PM -0600, Hans Petter Jansson wrote: > > > > I seriously doubt that GStringChunk is useful, because the gain from > > > > using non-aligned memory is lost if your strings don't fit the block > > > > size (e.g. too long strings as described by Jeff, or even just the last > > > > block not being completely filled). I'm in favor of obsoleting > > > > GStringChunk. > > > If true, then you should be able to prove it, and nothing is preventing > > > GStringChunk from returning aligned memory. > > > Are you guessing? > > As stated, it depends on the use case. > Did you try it? :-) > > Cache lines are often 64 bytes or longer with modern processors. If > the malloc() header is 16 bytes, and the string is padded to 16 bytes > boundaries, this can mean that a string with length 20 bytes takes up > 48 bytes. Two such 20 bytes may be separately allocated on different > pages, leading to a read of 128 bytes or more for two strings. Packed > tightly, 3 x 20 bytes can fit in one 64 byte cache line. Aligned or > un-aligned, reading fewer cache lines is cheaper. > > I've recently measured the effect of alignment on Intel Xeon and AMD > X2 processors for string operations (strpcpy() to be exact), and the > effect is only slight. > > This is why I suggest that any claims be shown with some sort of > benchmark. The opposite may be true than what was claimed. When I said that "the gain from using non-aligned memory is lost", I was referring to malloc() returning aligned memory, and saying that using non-aligned memory for strings (i.e. packing them) is a _good_ thing. So I guess we're in agreement here :) The loss is incurred when your blocks are not completely filled. However, see below. > > That's why I said long-lived. If the data is allocated and kept around > > for a long time, the space saved is more important than the CPU time > > lost. > Long lived doesn't mean frequently accessed. As a long time user of > Perl, and Java, I can say with some certainty that space utilization > is not usually a primary concern. That depends entirely on the device you're running it on. Morten's Gnumeric use case has changed my mind regarding GStringChunk, though - if we can amend the documentation to point out that the blocks must be much larger than the expected string size, and that care should be taken to use few GStrinkChunk allocators in an app (so there won't be a lot of half-empty "tail blocks" left around), I think we're good. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Scrolls in GTK
On Sun, 2006-11-19 at 19:10 +0100, Paweł wrote: > I would like to ask you to visit this topic on gnome-look.org: > http://gnome-look.org/content/show.php?content=48820 > > Sorry for my english, which may not be so good, but I'm keen on graphics > and during working in Gnome I see many things in GTK which can be made > much better. There is no need for changes to be big, but the effect I > think will be very good and the ergonomics improve. > Beautifull of simplicity :) The example pics don't seem to have "before" and "after" labels, but I assume you want scrollbars to merge visually with the scrolled views they apply to, eliminating the space (and additional line) that currently separate them in most (all?) GTK themes. I think I agree with your point - this would eliminate some visual noise. Maybe this can be done in a theme engine? Maybe it's something to consider for Clearlooks? -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: has anyone valgrind'd gtk?
On Sun, 2006-12-03 at 14:11 +, Ross Burton wrote: > GTK+ internally uses GSlice, which means you'll see lots of fake leaks. > Set G_SLICE=always-malloc when starting valgrind, and they'll probably > disappear. It's a good idea to use G_DEBUG=gc-friendly too, especially if you're looking for leaks. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: has anyone valgrind'd gtk?
On Wed, 2006-12-06 at 22:00 +0800, [EMAIL PROTECTED] wrote: > I've tied this, and also G_DEBUG=gc-friendly > > The reality is that gtk is leaking. > it's not just a matter of there being a pointer that wasn't cleared. > valgrind is reporting actual malloced memory that hasn't been freed. Nobody's disputed this (yet) - the env var suggestions should make valgrind report even more leaks :) > ==9422== LEAK SUMMARY: > ==9422==definitely lost: 5,318 bytes in 35 blocks. > ==9422==indirectly lost: 8,760 bytes in 432 blocks. > ==9422== possibly lost: 800 bytes in 20 blocks. > ==9422==still reachable: 2,065,986 bytes in 21,540 blocks. Something is definitely leaking. As Sven points out, it might just be your test case, but we can't be sure until we have all the details. > I'm going to start tracking some of these down. That would be awesome. Thank you! Places where GTK+ apps are "just using too much memory" at run-time are interesting too. > My REAL QUESTION(s) are who do I report fixes to? (quickly backed up by: if I > need help understanding what's going on, and specifically, why something isn't > being freed in the first place, who do i ask) ? Reporting fixes is best done in http://bugzilla.gnome.org/ . You can ask for help here, or if you just need a few pointers, you could try the #gtk+ IRC channel at irc.gnome.org. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: EggSequence
On Sat, 2007-01-27 at 03:01 +0100, Soeren Sandmann wrote: > A long time ago I wrote GSequence for the purpose of speeding up > Nautilus, which at the time was spending large amounts of maintaining > sorted lists of file. GSequence is a data structure that implements > the API of a list, but represents it internally as a balanced binary > tree. This allows things like g_sequence_insert_sorted() to run in > time O(log n) instead of O(n). I really like it. It looks easy to use for simple cases and flexible for more complex uses. The API is pretty clear. +1 vote for GLib inclusion. > The datastructure is accessed through iterators. These are stable > across all manipulations of the sequence, Ie., you can have an > iterator point to an item, then sort the sequence, and the iterator > will still point to the same item whereever it ends up. I'm not sure it's correct to call it an iterator when it's just a pointer to an internal data structure node. When a node is freed, any iterator pointing to that node will be freed as well, and that might not be what the user expects (e.g. she might expect it to point to the item that takes its place). An attempt to access the iterator after its corresponding node is removed will result in a crash, and there is also no way to validate the iterator. I don't think more robust iterators are worth the overhead for this data structure, but would you consider calling them items instead of iterators? I think it'd avoid some confusion. Also, the internals look slightly suboptimal in places: - Perhaps node_free() could be implemented recursively instead of with a GQueue, to save heap allocations? - Allocate nodes using GSlice instead of g_new/g_free()? That can be taken care of later, though. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: EggSequence
On Sun, 2007-01-28 at 01:50 +0100, Soeren Sandmann wrote: > Hans Petter Jansson <[EMAIL PROTECTED]> writes: > > I don't think more robust iterators are worth the overhead for this data > > structure, but would you consider calling them items instead of > > iterators? I think it'd avoid some confusion. > Well, they are actually _more_ stable than other things we call > iterators. GtkTree- and GtkTextIters become invalid as soon as you > make _any_ change to the data structure. GSequenceIters only become > invalid when you delete the item they point to. Also each GSequence > has a special iterator, the 'end' iterator which does not point to any > item in the sequence, but instead serves only as a marker. This is > consistent with iterator semantics, rather than pointer semantics. Fair enough. > The reason it uses GQueue for the stack is that the data structure is > a splaytree which is not necessarily balanced at all at any point in > time. This means freeing it recursively could in the worst case > involve O(n) stack use. So I used a GQueue to avoid excessive stack > load during free. It may be worthwhile replacing it with a GPtrArray > to improve memory use and locality. > > (In retrospect using a splaytree was probably not a wise decision. A > red/black tree might have been better, even though it would have a > code-complexity cost in some areas). Could we change the implementation (say, to RBT) without introducing API changes, in case it turns out to be a performance problem later? If not, I'd rather it be changed before we commit to it. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: EggSequence
On Mon, 2007-01-29 at 20:59 +0100, Soeren Sandmann wrote: > Yes, I think the implementation can be changed without API changes. > > If at some point we implement the aggregates that Jonathan mentioned > it would make a lot of sense to also move to a red/black or a btree at > the same time, since the rotations on _lookup_ that a splaytree does > make maintaining aggregates somewhat expensive. Cool. A comment in the source code itself explaining the potential improvements (and why they make sense) would be useful. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Usability of GSequence API
On Sat, 2007-02-17 at 02:52 +0100, Soeren Sandmann wrote: > Behdad Esfahbod <[EMAIL PROTECTED]> writes: > > - Some methods names hardly suggest the semantics of the operation. > > For example: > > > > void g_sequence_move (GSequenceIter*src, > > GSequenceIter > > *dest); > > > > What does it mean to move a iterator to another one? It's still not > > clear even if you s/GSequenceIter/GSequenceNode/. > It moves the item pointed to by src to the position given by dest. I'd > agree that it's unclear that 'src' and 'dest' are not really equals > here, but I don't see any good alternative names. How about g_sequence_move_before? The only case where that would come out imperfect would be when moving something to the end iter. But even then, you're inserting before the end-of-list, obviously - the end iter will be pushed down. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gvfs status report
On Thu, 2007-02-15 at 16:54 +0100, Alexander Larsson wrote: > In general I think that we will still use URIs to pass file references > between apps when doing things like DnD, cut-and-paste or when saving > filenames in config files. It seems hard to change this at this time, > and it has some advantages in that other applications also understand > such URIs (to some extent, vfs uris aren't always exactly like web > uris). However, internally in gio we immediately map the URI to a > mountpoint spec (which might not be mounted yet) and a path, and all > path operations happens in this form. Think of URIs like a > serialization form. > > The mapping from uri to mount spec is done by custom backend-specific > code. I arrived at this model after several false starts, and I think > its pretty nice. It means the backends and the client implementation > get a very clean view of the world, and all the weirdness of strange > URI schemes like smb is handled totally in one place in the client > library code. > > A large problem with gnome-vfs is that applications not specially > coded to use gnome-vfs will not be able to read non-local files. A > nice solution to this would be to use FUSE to let such apps use normal > syscalls to access the files. In general its quite tricky to map any > URI to a FUSE file, but with the mountpoint + filename setup gvfs uses > it is very easy to create a FUSE filesystem that lets you access all > the current vfs mounts. Could we standardize the local file system paths for non-gvfs apps, so we can reliably DnD to them and have them receive local paths? E.g. ~/.mounts/// Consider also apps that receive these local paths, store them and reference them in future sessions. I think it would be wise to include such functionality, or at least specifications, if we're going to replace gnome-vfs anyway. It would save worlds of pain in scenarios involving legacy or 3rd party apps. Having these paths map 1:1 to URIs (with translation functions?) would be excellent. It seems you've given it some thought - what are the tricky parts? -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
VFS for legacy apps (was: gvfs status report)
On Tue, 2007-02-20 at 09:24 +0100, Alexander Larsson wrote: [Snip] > In general, the way mountpoints work in unix is that they are mounted > over *one* directory, and don't mix things up with other mounts, so I > think the best solution would be to have each mountpoint be one > subdirectory under ~/.mounts (or whatever). > > The question is then, how do we name these subdirectories. I've come up > with two plausible versions. One, we use the full mount specification > and encode it (with escaping) in the mountpoint name. So, you'd have > ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt. > > Two, each mountpoint generates a display name that is used in the gui > for the mountpoint. An example for smb would be "$share share at > $server". This is weakly unique[1] on the same machine. We can make it > guaranteed unique in the daemon and use this as the mountpoint name. > Like this > ~/.mount/$share share at $server/dir/file.txt. > > The second method isn't really possible to map backwards to the original > source of the mountpoint if the mountpoint is not mounted. However in > almost all cases where we access a file from it, it will be mounted > already, and thus mapped in the same place. So this isn't really a > problem in practice, especially since the desktop itself natively > handles gvfs mounts. And if its not mounted you can easily display a > warning that "$share share at $server" isn't mounted which is nice and > readable. This isn't really all that different to traditional unix > mounts. For instance you can't map from a nfs mountpoint > like /mnt/bigserver to the exact nfs details of the mounpoint (if its > not mounted). This won't work. We need to be able to extract all the mount information from the path, so that if the app stores the path across sessions, say, in "recent documents", the FUSE layer will know what to do when it's accessed later. However, the first method you describe: ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt sounds perfect. It's rich (we can get back the mount info later), extensible (we don't have to figure out the entire set of potential mount options in advance) and fairly simple (the root nodes are all direct children of ~/.mounts). > The advantage of method one is that you can actually take such a path > and extract enought information to mount the path. On the other hand, it > looks like total ass. Pray that it doesn't show up in the UI somewhere. Most URIs also look like total ass. It depends on what you're used to. And ass or not, being able to access a document on a remote share when it's launched with or dragged to a legacy app trumps it. I'm sure users of e.g. MPlayer or Acroread would thank us. There are also plenty of GNOME apps that never worked with non-local files :) -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote: > On Thu, 2007-02-22 at 03:10 -0600, Hans Petter Jansson wrote: > > However, the first method you describe: > > > > ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt > > > > sounds perfect. It's rich (we can get back the mount info later), > > extensible (we don't have to figure out the entire set of potential > > mount options in advance) and fairly simple (the root nodes are all > > direct children of ~/.mounts). > You're probably always going to need type, server and share though, so > maybe you can make it a bit more readable: > > ~/.mounts/smb:$server:$share/dir/file.txt > > Extra options can go on the end. > > Also I'd probably avoid ';' just in case bash goes anywhere near it. Yeah - the actual syntax is still up in the air, but we need to define it carefully. Do you think ':' is a good separator? I'm not sure you'll always be accessing a share (subdirectory) on the server. I guess we could make the share be "/" in that case... -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 13:51 +0100, Alexander Larsson wrote: > On Thu, 2007-02-22 at 12:38 +, Damon Chaplin wrote: > > You're probably always going to need type, server and share though, so > > maybe you can make it a bit more readable: > > > > ~/.mounts/smb:$server:$share/dir/file.txt > > > > Extra options can go on the end. > > > > Also I'd probably avoid ';' just in case bash goes anywhere near it. > Sure, those are requred. But say we have two optional things, like user > and domain, as in smb:server:share:user:domain. But what do we then do > if user is unset, but domain isn't. I guess one could do > smb:server:share::domain. Still, it requires very specific handling of > each type of share with a specified option order etc. A key=value > approach is more generic. I suppose ~/.vfs/smb:$server:$share/dir/file.txt:option=$value:option=$value is a workable compromise. It might even be what Damon was indicating. Now that we're picking on details, I'd say that .vfs or .gvfs would be a better base directory than .mounts too. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps (was: gvfs status report)
On Thu, 2007-02-22 at 14:44 +0100, Alexander Larsson wrote: > On Thu, 2007-02-22 at 13:49 +0100, Alexander Larsson wrote: > > On Thu, 2007-02-22 at 10:33 +0100, Alexander Larsson wrote: > > As a further example of this I tried OSX. It has a system similar to the > > first proposal. I.E. When you mount smb://server/share in the finder it > > appears as the unix mount /Volume/server;share, and connecting to > > ftp://ftp.gnome.org/ gives you a /Volume/ftp.gnome.org mount. > > > > It handled the recent files case by not showing the recently opened file > > in the recent files menu when it was on a share that is no longer > > mounted. However, if I remounted it it appeared again. (Although i did > > have to restart the app, which is sort of crap.) > In fact, its likely they implement this by just stat()ing all the files > in the recent list. This is a great example of where automounting would > royaly screw things up. Given a traditional unix system there wouldn't > be anything bad with a solution like that (in fact, it would be very > nice to not show deleted files in the recent menu). However, if any stat > can lead to indefinite blocking and displaying of random authentication > dialogs you suddenly have to do something much more complicated in order > to not suck. That's a good point. To make that suck less, you'd probably have to - Immediately deny any access to unmounted shares. - Pop up a dialog asking the user if it should be mounted (if the mount metadata could be converted to a more display-friendly string, such as a URI or even a chosen name, that would be great). - Optionally mount it. The bad part is that the application's "access denied" and the "I think you're trying to mount something" dialogs would pop up simultaneously. With gnome-keyring integration, this problem would largely go away, though. In most cases, gvfs could fetch the auth information transparently then go ahead and mount. Sure, it'll block the calling application, but if it's using a blocking open(), it always blocks to some extent anyway. We could make the timeout fairly short (say, 10 seconds) when we know we're dealing with a legacy app. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps
On Thu, 2007-02-22 at 22:26 +0100, Nikolai Weibull wrote: > On 2/22/07, Hans Petter Jansson <[EMAIL PROTECTED]> wrote: > > ~/.mounts/type=smb-share;server=$server;share=$share/dir/file.txt > I just want to point out that there's a freedesktop specification for > where things should be stored. Not many seem to respect it, but I, > for one, really would appreciate it if people would, as the root of my > ~ isn't a junkyard for files and directories. My OCD really needs it > to be in order. > > http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html The relevant part appears to be: "$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used." So I guess our default would be ~/.local/share/vfs/ ? -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps
On Fri, 2007-02-23 at 09:30 +0100, Alexander Larsson wrote: > On Thu, 2007-02-22 at 14:51 -0600, Hans Petter Jansson wrote: > > That's a good point. To make that suck less, you'd probably have to > > > > - Immediately deny any access to unmounted shares. > > - Pop up a dialog asking the user if it should be mounted (if the mount > > metadata could be converted to a more display-friendly string, such as a > > URI or even a chosen name, that would be great). > > - Optionally mount it. > So, when the app reads the data for recent files and stats it, or does > some other similar operation you'll pop up a dozen dialogs allowing you > to mount things like ftp.gnome.org again. You click "no" several times, > and two seconds later they all pop up again. Believe me, things like > this happen, all the time. I have to be extremely careful in nautilus > for example to never ever access (even get info about) things like > history or bookmarks except when the user explicitly browse into them, > otherwise we pop up dialog to left and right, when the user don't expect > this at all. Isn't connection sharing in the daemon supposed to prevent this? If we have no low-level way to prevent it, I think we're in trouble anyway. > I much prefer a system where the app can either just ignore the failed > stat (if it was an "unimportant" operation), or in case an open fails > display an error that the pathname couldn't be opened, with a pathname > that users can understand. Especially when said pathname is also likely > to appear in the user interface (in the file selector). You can convert it to a URI on display, or even reach into a database of previously mounted user-named services to get a pretty name. > > The bad part is that the application's "access denied" and the "I think > > you're trying to mount something" dialogs would pop up simultaneously. > > > > With gnome-keyring integration, this problem would largely go away, > > though. In most cases, gvfs could fetch the auth information > > transparently then go ahead and mount. > Its unfortunate that due to todays stateless gnome-vfs that doesn't ever > reuse server connections between processes we have to use gnome-keyring > as a poor-mans connection-sharing. This is really not a good idea in > general, as it means you tend to store all your passwords (like smb or > sftp passwords that are often the same as your system password!) in > gnome-keyring. Which is *not* recommended as good password hygiene. > (i.e. anyone in front of your unlocked desktop, say when you're on > lunch, can easily extract all your passwords from gnome-keyring. Handing > out passwords is after all what gnome-keyring is designed to do.) > > Lets not propagate such use further. I agree that security is important, but the exploit would have to go something like this: 1) You leave your computer on during lunch break without locking the screen (for cube slaves) or the door to your office (for execs). 2) You work with your worst enemy and you don't know that he/she is just that, or you'd have fired her, quit your job or at least locked your screen. 3) Said enemy knows how to make the already running gnome-keyring process give up its passwords (remember, if it restarts she'll need the master password that your keys are encrypted with). I can see this being done with significant gdb work. It's a possible, but very theoretical threat. Here are some much more realistic threats: A) The shares are already mounted (gnome-keyring or not), so the attacker will never need the passwords. B) Since gvfs keeps asking for passwords, you maintain a manual keyring on a postit note. The attacker finds the note. C) The attacker installs a prefab keylogger while you're out. The lesson is that you cannot protect yourself from password-extraction attacks against an unguarded, logged-in desktop, and in scenario B), which we are promoting by not using a keyring, the attacker doesn't even need to be logged in. Finally, the long-term security threat to the GNOME desktop that I'm most worried about is trojans - but these would affect all password-handling applications equally. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps
On Fri, 2007-02-23 at 09:16 +0100, Alexander Larsson wrote: > On Thu, 2007-02-22 at 14:22 -0600, Hans Petter Jansson wrote: > > I suppose > > > > ~/.vfs/smb:$server:$share/dir/file.txt:option=$value:option=$value > You mean > ~/.vfs/smb:$server:$share:option=$value:option=$value/dir/file > I assume? No, I was assuming that the distinction between "share" and the first path element was arbitrary. Which it might not be, I guess. > > is a workable compromise. It might even be what Damon was indicating. > > Now that we're picking on details, I'd say that .vfs or .gvfs would be a > > better base directory than .mounts too. > This would work, and would look better. It still requires specific code > for each possible backend to map from path back to the mount info > though. (i.e. you need to know that for smb the first two items are > server and share.) Which protocols don't require a server address? Which don't require a path relative to the server? If none, will such realistically exist in the future? -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps
On Fri, 2007-02-23 at 10:56 +0100, Alexander Larsson wrote: > On Thu, 2007-02-22 at 17:44 -0600, Hans Petter Jansson wrote: > > So I guess our default would be ~/.local/share/vfs/ ? > XDG_DATA_HOME is basically the user-specific version of /usr/share/. You > don't mount your stuff in /usr/share. > > Its not only weird, its a pretty bad idea. Eventually such a pathname > will show up in the ui (say in the file selector) and the user will > navigate to ~/.local/share which is supposed to be a hidden directory > for application data. (It contains things like user-specific > mime-application mappings and mime additions.) I agree with you, but I'd like to hear Nikolai's take on it too. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps
On Sat, 2007-02-24 at 14:18 +0100, Nikolai Weibull wrote: > I agree with both of you. > > Perhaps we need another variable in the specification mentioned, such > as XDG_MOUNT_HOME that defaults to ~/.local/mount or similar. > > I figured I'd at least mention it so that we thought all aspects of > this through. It's bad enough DBus and fontconfig don't use the > variables suggested by the specification, simply dumping their > cache/session data in subdirectories of ~. But that's really for > another mailing list. It may also be a battle that we've already lost: hpj [~] echo .* | wc -w 140 However, if you talk to the people in question and get something into the spec that applies to VFS, maybe Alex will listen :) -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps
On Mon, 2007-02-26 at 10:45 +0100, Alexander Larsson wrote: > On Fri, 2007-02-23 at 15:11 -0600, Hans Petter Jansson wrote: > > Which protocols don't require a server address? Which don't require a > > path relative to the server? If none, will such realistically exist in > > the future? > In gvfs currently there is smb-network (i.e. smb:///) > In gnome-vfs there are things like computer:, network:, cdda:, burn:. > Another example would be the remote version of file:/// (access files on > the machine that runs the session bus as discussed earlier in this > thread). Good point. So I guess the protocol identifier is the only element that can be fixed, and the rest must be option=$value. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: VFS for legacy apps
On Mon, 2007-02-26 at 11:13 +0100, Alexander Larsson wrote: > On Fri, 2007-02-23 at 15:03 -0600, Hans Petter Jansson wrote: > > On Fri, 2007-02-23 at 09:30 +0100, Alexander Larsson wrote: > > > So, when the app reads the data for recent files and stats it, or does > > > some other similar operation you'll pop up a dozen dialogs allowing you > > > to mount things like ftp.gnome.org again. You click "no" several times, > > > and two seconds later they all pop up again. Believe me, things like > > > this happen, all the time. I have to be extremely careful in nautilus > > > for example to never ever access (even get info about) things like > > > history or bookmarks except when the user explicitly browse into them, > > > otherwise we pop up dialog to left and right, when the user don't expect > > > this at all. > > Isn't connection sharing in the daemon supposed to prevent this? If we > > have no low-level way to prevent it, I think we're in trouble anyway. > Not if you click 'no'. I.E. you had no intention to connect up with a > gazillion ftp servers from your recent files. I mean, I guess the daemon > could see that your trying to connect again to the same place you just > said no to and "magically" decide that this time you probably didn't > mean it. But such magic rarely work right. A simple policy would be if the user says "no" to establishing a connection once, then the answer will always be "no" until the user explicitly mounts it. Similar to turning the "mount on login" option off. The daemon would also serialize the dialogs, and only show one at a time. Then, further mount requests for a share that's already in the queue, can be dropped. > > > I much prefer a system where the app can either just ignore the failed > > > stat (if it was an "unimportant" operation), or in case an open fails > > > display an error that the pathname couldn't be opened, with a pathname > > > that users can understand. Especially when said pathname is also likely > > > to appear in the user interface (in the file selector). > > You can convert it to a URI on display, or even reach into a database of > > previously mounted user-named services to get a pretty name. > Ah, you could. An ideal app would (actually I guess an ideal app might > use gvfs instead of the fuse mountpoint). But acroread won't, nor would > most 3rd party apps. They will however likely show you the pathname that > failed to open. If we can have something like a per-user fstab so the options can be recovered, I concur. > > I agree that security is important, but the exploit would have to go > > something like this: > > > > 1) You leave your computer on during lunch break without locking the > > screen (for cube slaves) or the door to your office (for execs). > > > > 2) You work with your worst enemy and you don't know that he/she is just > > that, or you'd have fired her, quit your job or at least locked your > > screen. > > > > 3) Said enemy knows how to make the already running gnome-keyring > > process give up its passwords (remember, if it restarts she'll need the > > master password that your keys are encrypted with). I can see this being > > done with significant gdb work. > gdb work? Why not make a tiny app (a few lines of python maybe) that > calls the gnome-keyring API and just *ask* it for the password. > gnome-keyring is after all specially designed to make it easy for apps > to retrieve passwords. In fact, you probably just need to click on > gnome-keyring-manager and select the right share in the UI. Ah, I was thinking that gnome-keyring restricts access to a list of specific binaries - but I forgot that you can add more once the keyring is unlocked, and that gnome-keyring-manager will likely already be in the list. There are still ways to mitigate this (and they would also make what you deem "unimportant passwords" more secure against casual intrusion): - Make gnome-keyring-manager always require the master password when it's opened. It makes sense because you rarely open it and when you do, you usually close it before leaving the desktop - users are more likely to see their own passwords in the UI and understand that it's insecure. Any other applications that offer easy access to the user's keyring would have to be amended similarly. - Require the master password when you add to the list of allowed binaries. Currently you have to yea or nay it, and we could add a password entry to this dialog. This will also not happen often. It's still just obfuscation, but with local attacks on a running,
Re: VFS for legacy apps
On Mon, 2007-02-26 at 11:28 +0100, Alexander Larsson wrote: > On Sat, 2007-02-24 at 14:18 +0100, Nikolai Weibull wrote: > > Perhaps we need another variable in the specification mentioned, such > > as XDG_MOUNT_HOME that defaults to ~/.local/mount or similar. > I really think we should default to something directly in ~/ so that an > "up" operation doesn't get you to some weird hidden place. However, > honoring an env var sounds ok. (Of course, there is the risk that all > apps won't be honoring the env var.) I tend to agree. We can only hope that future 3rd party apps will not try to modify the mount options without going through gvfs. For existing apps that don't know anything about VFS, things should be fine as long as the path does not change out from under them. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_get_user_config_dir leaks memory ?
On Mon, 2007-03-26 at 20:57 +0100, Ross Burton wrote: > On Mon, 2007-03-26 at 20:40 +0100, Rúben Fonseca wrote: > > > So my question is, is g_get_user_config_dir really leaking? Or it is > > > just a Valgrind problem? Can I make it not to leak? > > Looking up entries in the password database (thats the getpwnam_r call) > can potentially take a long time (say the database stored in a LDAP > server at the other end of slow VPN link), so GLib fetches it once and > caches it. This is why you shouldn't free it. So yes, technically it > is leaking, but it's a one-off cost (it won't grow over time) and is > good for you. Just ignore it: someone really should sit down and make > an officially maintained suppressions file for Valgrind for the X11 and > GLib "leaks". If it's cached, shouldn't it still be reachable? -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_get_user_config_dir leaks memory ?
On Mon, 2007-03-26 at 21:10 -0400, Havoc Pennington wrote: > Hans Petter Jansson wrote: > > If it's cached, shouldn't it still be reachable? > valgrind has a (mostly useless) mode that shows reachable-but-not-freed > blocks. Yes, but then it says "still reachable". This one says "definitely lost". Probably in error. Also, the last time I checked, valgrind would only let you suppress messages about invalid accesses, not leaked memory. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: g_get_user_config_dir leaks memory ?
On Tue, 2007-03-27 at 06:46 -0700, Carl Worth wrote: > On Mon, 26 Mar 2007 19:19:22 -0600, Hans Petter Jansson wrote: > > Also, the last time I checked, valgrind would only let you suppress > > messages about invalid accesses, not leaked memory. > No, it definitely allows suppressions for leaked memory, via a > Memcheck:Leak suppression entry. I've included an example below from > what cairo is using to ignore still-reachable memory from Xrm. > > But you should be able to easily get exactly what you want from > valgrind with its --gen-suppressions=yes option. Ok. It was a long time ago :) -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Smooth Scrolling
On Tue, 2007-03-27 at 15:54 +0200, Xavier Bestel wrote: > On Tue, 2007-03-27 at 07:37 +0100, Alex Jones wrote: > > A few years ago there used to be a distributor patch in Gentoo to enable > > this, and it was sweet. What happened, here? > I dunno, but it's more than sweet. Whoever remember the text editor > CygnusED, which had a very smooth scrolling, vblank-synchronized, > progressive, knows that this helps wonderfully to "know where you are" > once you have scrolled. Currently in GTK+, after hitting the scrollbar > you have to think for a moment to let your eyes find the cursor again. Oh man, CygnusED! The scrolling was indeed very nice, and I seem to remember that it used a short acceleration ramp when starting to scroll, and when stopping. It was pleasant, letting me page up and down much quicker than I can do in e.g. emacs or gedit now. It would be cool if we could bring that back in the context of a non-extinct platform. -- Hans Petter ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
