Am Donnerstag, den 13.12.2007, 17:31 +0100 schrieb Alexander Larsson:
>
> typedef enum {
> G_FILE_QUERY_INFO_FLAGS_NONE = 0,
> G_FILE_QUERY_INFO_NOFOLLOW_SYMLINKS = (1<<0)
> }
>
> vs
>
> typedef enum {
> G_FILE_MONITOR_FLAGS_NONE = 0,
> G_FILE_MONITOR_FLAGS_MONITOR_MOUNTS = (1<<0)
> }
On Fri, 2007-12-14 at 15:49 +0100, Sven Herzberg wrote:
> Alexander Larsson wrote:
> > I'm for . It seems more inline with all our other libraries.
> > Only gobject does the thing.
> >
>
> Shouldn't be enough? This would really drop 4 letters that every
> gio-using developer had to type and
On Dec 14, 2007 3:27 AM, Alexander Larsson <[EMAIL PROTECTED]> wrote:
> Anything that has cancellable operations (things like libsoup or
> whateveR) should use GCancellable. And GAsyncResult is a very powerful
> pattern for doing async operation that all libraries with async
> operations should ta
t;
>>>>> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
>>>>>
>>>>>> Hey everybody,
>>>>>>
>>>>>> We've been doing a GIO API review in the last couple of days and
>>>>>
Matthias Clasen wrote:
> On Dec 13, 2007 1:21 PM, Martyn Russell <[EMAIL PROTECTED]> wrote:
>
>> I don't really see the need for adding symbols to the library to
>> represent 0. If there is only one "flag" in each of these that matters,
>> doesn't it make more sense to just have a boolean?
>>
>
>
14 dec 2007 kl. 09.27 skrev Alexander Larsson:
Hi,
> On Thu, 2007-12-13 at 19:19 +0100, Mikael Hallendal wrote:
>
>> For example, if we plan to never use the GAsync infrastructure for
>> anything other than GIO there is a point to put it under the GIO
>> namespace as it shows where it belongs and
On Thu, 2007-12-13 at 19:19 +0100, Mikael Hallendal wrote:
> For example, if we plan to never use the GAsync infrastructure for
> anything other than GIO there is a point to put it under the GIO
> namespace as it shows where it belongs and what part of GLib it is
> used for. It also means w
On Thu, 2007-12-13 at 19:45 +0100, Richard Hult wrote:
> Mikael Hallendal wrote:
> > I just wanted to clarify though that it's not so much for technical
> > reasons I suggested that we namespace a bit more carefully.
> >
> > For example, if we plan to never use the GAsync infrastructure for
>
On 13/12/2007, Martyn Russell <[EMAIL PROTECTED]> wrote:
> Alexander Larsson wrote:
> > On Thu, 2007-12-13 at 14:43 +0100, Michael Natterer wrote:
> >> Alexander Larsson wrote:
> >>> It just adds new types and type relations you have to learn, and forces
> >>> you to remember that you have to cast
On Dec 13, 2007 1:21 PM, Martyn Russell <[EMAIL PROTECTED]> wrote:
> I don't really see the need for adding symbols to the library to
> represent 0. If there is only one "flag" in each of these that matters,
> doesn't it make more sense to just have a boolean?
>
This is not adding any symbols to
Hi,
Martyn Russell wrote:
> I don't really see the need for adding symbols to the library to
> represent 0. If there is only one "flag" in each of these that matters,
> doesn't it make more sense to just have a boolean?
>
Flags are almost always preferable to booleans, compare -
gtk_box_pack_
Mikael Hallendal wrote:
> I just wanted to clarify though that it's not so much for technical
> reasons I suggested that we namespace a bit more carefully.
>
> For example, if we plan to never use the GAsync infrastructure for
> anything other than GIO there is a point to put it under the GIO
Alexander Larsson wrote:
> On Thu, 2007-12-13 at 17:25 +0100, Carlos Garnacho wrote:
>> Hi all!,
>>
>> On mar, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
>>> Hey everybody,
>>>
>>> We've been doing a GIO API review in the last couple of
13 dec 2007 kl. 12.51 skrev Alexander Larsson:
Hi,
> On Wed, 2007-12-12 at 16:48 +0100, Mikael Hallendal wrote:
>> 12 dec 2007 kl. 14.59 skrev Alexander Larsson:
>>
>> Hi,
>>
>>> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
>>
>>>
A big issue is that GIO wastes namespaces massi
On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> There is no need to break the common prefix for global things:
>
> g_push_current_cancellable -> g_cancellable_push_current
> g_pop_current_cancellable -> g_cancellable_pop_current
Done.
__
On Thu, 2007-12-13 at 17:25 +0100, Carlos Garnacho wrote:
> Hi all!,
>
> On mar, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> > Hey everybody,
> >
> > We've been doing a GIO API review in the last couple of days and
> > here is the list of
On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> GFile:
> ==
>
> g_mount_for_location should probably be g_file_mount_for_location
I've changed this to g_file_mount_enclosing_volume()
___
gtk-devel-list mailing list
gtk-devel-list@gnom
Hi all!,
On mar, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> Hey everybody,
>
> We've been doing a GIO API review in the last couple of days and
> here is the list of comments and issues we've come up with:
>
I Just wanted to raise another concern I hav
Alexander Larsson wrote:
> On Thu, 2007-12-13 at 14:43 +0100, Michael Natterer wrote:
>> Alexander Larsson wrote:
>>> It just adds new types and type relations you have to learn, and forces
>>> you to remember that you have to cast to some common class to do things
>>> like cancelling a directory
Hey everybody,
> >>>>
> >>>> We've been doing a GIO API review in the last couple of days and
> >>>> here is the list of comments and issues we've come up with:
> >>>>
> >>>>
> >>>> General:
> &g
On Thu, 2007-12-13 at 14:43 +0100, Michael Natterer wrote:
> Alexander Larsson wrote:
> > It just adds new types and type relations you have to learn, and forces
> > you to remember that you have to cast to some common class to do things
> > like cancelling a directory monitor. It adds nothing us
Alexander Larsson wrote:
> On Wed, 2007-12-12 at 16:46 +0100, Michael Natterer wrote:
>> Alexander Larsson wrote:
>>> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
>>>> Hey everybody,
>>>>
>>>> We've been doing a GIO API rev
Alexander Larsson wrote:
> On Wed, 2007-12-12 at 17:33 +0100, Michael Natterer wrote:
>> Alexander Larsson wrote:
>>> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
G*Monitor:
==
GFileMonitor -> GIOMonitorFile
GDirectoryMonitor -> GIOMonitorDirecto
On Wed, 2007-12-12 at 17:33 +0100, Michael Natterer wrote:
> Alexander Larsson wrote:
> > On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> >> G*Monitor:
> >> ==
> >>
> >> GFileMonitor -> GIOMonitorFile
> >> GDirectoryMonitor -> GIOMonitorDirectory
> >>
> >> Wouldn't it ma
On Thu, 2007-12-13 at 12:34 +0100, Mathias Hasselmann wrote:
> Am Donnerstag, den 13.12.2007, 12:17 +0100 schrieb Alexander Larsson:
> > If we add things like GSettings to libgio (to avoid adding yet
> > more .so's) then things look even more weird. GIOSettings?
>
> Off-topic, but random though s
On Wed, 2007-12-12 at 16:48 +0100, Mikael Hallendal wrote:
> 12 dec 2007 kl. 14.59 skrev Alexander Larsson:
>
> Hi,
>
> > On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
>
> >
> >> A big issue is that GIO wastes namespaces massively:
> >> g_app, GAsync, g_buffered, g_cancellable, g
Am Donnerstag, den 13.12.2007, 12:17 +0100 schrieb Alexander Larsson:
> If we add things like GSettings to libgio (to avoid adding yet
> more .so's) then things look even more weird. GIOSettings?
Off-topic, but random though since we couldn't find a name of the
utility .so between libgobject and l
On Wed, 2007-12-12 at 16:46 +0100, Michael Natterer wrote:
> Alexander Larsson wrote:
> > On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> >> Hey everybody,
> >>
> >> We've been doing a GIO API review in the last couple of days and
> >
On Wed, 2007-12-12 at 16:53 +0100, Murray Cumming wrote:
> On Wed, 2007-12-12 at 16:37 +0100, Alexander Larsson wrote:
> > > >> GAsnc*-> GIOAsync*
> > > >> G*Stream -> GIOStream*
> > > >> GIcon -> GIOIcon
> > > >> G*Icon-> GIOIcon*
> > > >> GCancellable -> GIOCancella
Hi,
On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> We stronlgy suggest to use a common g_io/GIO prefix for all
> functions/types in GIO.
>
> GAsnc*-> GIOAsync*
> G*Stream -> GIOStream*
> GIcon -> GIOIcon
> G*Icon-> GIOIcon*
> GCancellable -> GIOCancella
Alexander Larsson wrote:
> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
>> G*Monitor:
>> ==
>>
>> GFileMonitor -> GIOMonitorFile
>> GDirectoryMonitor -> GIOMonitorDirectory
>>
>> Wouldn't it make sense to have a common (perhaps abstract) base class here,
>> or derive one
On Wed, 2007-12-12 at 16:37 +0100, Alexander Larsson wrote:
> > >> GAsnc*-> GIOAsync*
> > >> G*Stream -> GIOStream*
> > >> GIcon -> GIOIcon
> > >> G*Icon-> GIOIcon*
> > >> GCancellable -> GIOCancellable
> > >> ...
> > >
> > > I strongly oppose this.
> >
> > I perso
12 dec 2007 kl. 14.59 skrev Alexander Larsson:
Hi,
> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
>
>> A big issue is that GIO wastes namespaces massively:
>> g_app, GAsync, g_buffered, g_cancellable, g_content, g_data,
>> g_desktop, g_directory, g_drive, g_file, g_filename, g_
Alexander Larsson wrote:
> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
>> Hey everybody,
>>
>> We've been doing a GIO API review in the last couple of days and
>> here is the list of comments and issues we've come up with:
>>
>>
I have to support regarding the stream and file class names:
"GIOInputStreamUnix"
reads to me, like using a "Unix" class which is in the "InputStream"
namespace, that's embedded in the "GIO" namespace:
GIO::InputStream::Unix
So using that naming conventions input and output stre
On Wed, 2007-12-12 at 15:13 +, Martyn Russell wrote:
> Alexander Larsson wrote:
> > On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> >>
> >> GAsnc*-> GIOAsync*
> >> G*Stream -> GIOStream*
> >> GIcon -> GIOIcon
> >> G*Icon-> GIOIcon*
> >> GCancellable
Alexander Larsson wrote:
> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
>>
>> GAsnc*-> GIOAsync*
>> G*Stream -> GIOStream*
>> GIcon -> GIOIcon
>> G*Icon-> GIOIcon*
>> GCancellable -> GIOCancellable
>> ...
>
> I strongly oppose this.
I personally prefe
On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> Hey everybody,
>
> We've been doing a GIO API review in the last couple of days and
> here is the list of comments and issues we've come up with:
>
>
> General:
>
>
> It seems GI
Sorry for mis-following-up and resending, i have too many mail accounts.
On Wed, 2007-12-12 at 00:25 +, Emmanuele Bassi wrote:
> On Tue, 2007-12-11 at 21:22 +0200, Vincent Geddes wrote:
> > Hi,
> >
> > On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> > > Also, subclasses shoul
On Tue, 2007-12-11 at 21:22 +0200, Vincent Geddes wrote:
> Hi,
>
> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> > Also, subclasses should probably append their name, not prepend it:
> >
> > GFilterOutputStream -> GIOOutputStreamFilter
> > GUnixOutputStream -> GIOOutputStreamUni
On Tue, 2007-12-11 at 15:37 -0500, Jürg Billeter wrote:
> It's not only different from the naming conventions in those
> programming languages, it's also different from plain English, as far
> as I can tell as a non-native speaker.
But then again, it's not a human language...
--
behdad
http://be
On Tue, 2007-12-11 at 21:22 +0200, Vincent Geddes wrote:
> Hi,
>
> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> > Also, subclasses should probably append their name, not prepend it:
> >
> > GFilterOutputStream -> GIOOutputStreamFilter
> > GUnixOutputStream -> GIOOutputStreamUni
Hi,
On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:
> Also, subclasses should probably append their name, not prepend it:
>
> GFilterOutputStream -> GIOOutputStreamFilter
> GUnixOutputStream -> GIOOutputStreamUnix
> ...
>
> This makes the file and inheritence structure much clearer
Hey everybody,
We've been doing a GIO API review in the last couple of days and
here is the list of comments and issues we've come up with:
General:
It seems GIO allows individual files to be included, this should be
avoided like gobject does it:
#if !defined (__GLIB_GIO_
44 matches
Mail list logo
