Meeting on irc.gnome.org:#gtk-devel Meeting started October 19 2004 17:00 EST (21:00 UTC) In attendence: Owen Taylor (owen), Jonathan Blandford (jrb), Manish Singh (yosh), Matthias Clasen (matthias), Tor Lillqvist (tml), Federico Mena Quintero (federico), John Ehresman (jpe), Ray Strode (halfline), Robert Ögren (roboros), Maciej Katafiasz (mathrick) ok, we seem to be reasonably complete. do we have agenda items ? I'd like to discuss the api patches that need to be done before we can declare a slush freeze * federico panics a bit #101792? does that mean that gtkfilechooserextension will not make it into 2.6? I'm updating the spec for the "replace the whole file list" bit, and to make the API not involve GtkFileSystem internals but it's all very muddy still federico: sounds like a no federico: if it is still very muddy... yeah, exactly :) the major things I have on my list are desktop entry parser, hig dialog api, clipboard persistency sigh, no one ever sent a patch for #135901 tml: did we ever agree on a strategy for handling filename encodings ? matthias: There is a patch with a new strategy on the bug i think we agreed to use on-disk encoding on Unix, and UTF-8 on Windows (thus requiring apps to open files with g_open if the name is constructed from something that GLib gave them, etc) and the latest patch implements that ? matthias: Basicall,y it behaves as currently with old binaries, but if you recompile, you get new symbols that act the way that I wanted them to work matthias: yep matthias: The code to do that, not suprisingly, is rather unpleasant owen: cpp magic ? matthias: yes, to some extent tml: Did I mention to you that I thought that there shouldn't be a separate gfilewrappers.h, it should be part of gprintf.h, or maybe we need a new gstdio.h that includes both owen: yes. putting it in gprintf.h would be fine with me. Hmm, though filewrappers.h pulls in sys/stat.h too. Blech. Still, probably best not too explode the number of separate headers people need to include Needs API docs, of course owen: I don't have the patch at hand. is it ok that gprintf.h is not included in glib.h ? matthias: The point is that gfilewrappers also needs to reference FILE *, so it can't be in glib.h either owen: ah, ok tml: g_win32_get_windows_version() looks very mildly non-threadsafe. By GLib policy, it should either use GOnce, or get called on g_thread_init() except if one would know for sure that FILE is always typedeffed as struct _iobuf? Is struct _iobuf mandated in the C standard? Then including stdio.h wouldn't be necessary. tml: I definitely don't think we should be relying on it. tml: I would not rely on it. putting the file wrappers in gprintf.h is a good compromise, i'd say it might be something configure would find out? tml: No, it would be worse to sometimes include stdio.h than to always include it I'd rename gfilewrappers.h to gstdio.h and make it include gprintf.h owen: ok. i'll attach notes to the bug tml: the general approahc seems about as good as we are going to get so it looks like the patch needs one more iteration before it can go in... can we switch to the desktop entry parser now ? thats #139974 the main question I have about it is if we can find a better name for it, since it is in fact a generic ini file parser GIniFile GKeyFile? I haven't come up with any good alternatives, though. g_ini_ looks funny, and g_config_ is dangerously close to GConf g_config definitely should be out since we aren't recommending this (I think) for apps to store config in GkeyFile comes fromthe fact that it is basically storing key-value pairs owen: right. I think GKeyFile is good *g_key_file_new_from_file().... GKeyFileParser ? GSimpleConfFile? g_key_set_new_from_file()? Is that better? owen: might get confused with GDataSet ? matthias: Yeah. jamesh pointed out that added Parser to end of it isn't really fitting because it does more than parse. It is an in memory representation of the file apart from renaming, there are some special cases for desktop entry parsing which should be undone GKeyFile probably is likely OK even if it is the memory representation of the filoe eg the default legal_start_tags are the ones needed for desktop entries and the docs are written towards parsing desktop entries I think the GDesktopEntryFlags needs some reversals to give the right defaults for '0' ok one thing I wondered about is how compatible the "ini file" syntax of desktop entries is with traditional windows ini files since people might be tempted to use the parser on win32 as well matthias: that's an interesting point. I haven't ever tried it with .ini files one difference is comments, I think. Rays parser treats # as single-line-comment marker, whereas on win32 ; seems to be more commonly used my parser won't accept ; for comments and it probably can't, since ; may occur in content also translated keys are something desktop files have that i don't ini files do *think tml: do you think people would use a glib ini file parser on win32, or does windows have a good native api for that ? i don't think people would use it for that. software that uses ini files already parses themn some way, and new software presumably won't use the win32 traditional ini files anyway good, then it is mainly a matter of documenting the exact syntax that is accepted and pointing out where it differs from traditional win32 ini files maybe adding a BNF grammar description or something similiar to the docs would be good. the next question I have is about andersca's clipboard persistency work. tml, did you see the proposed api ? i am pretty sure there is win32 api to read ini files, but can't remember it right now matthias: yes, but haven't had time to ponder it totally not on agenda, but was splitting GtkTreeModel into Glib proper ever considered? I've seen it requested somewhere, but can't find bug for it owen: maybe changing g_key_file_new_from_file to g_key_file_new_from_filename or g_key_file_new_from_path would be better? mathrick: It's been rejected in the past as too much work to be interesting jrb: ic mathrick: why would that be a win ? you're likely to need gtk+ anyway to make use of your model... matthias: well, true that, but I think it was someone from mc team (?) proposing that. Don't really remember though, I only know it was "pity it isn't glib, as we could really use it" kind of request matthias: FYI: the Win32 ini file API is GetPrivateProfileString() haflline: I think new_from_file() is best - or you could go with new() and load_from_file() matthias: generic tree structure isn't very uncommon thing to use ;) tml: thanks, will mention it in the docs perhaps halfline: new_from_filename() doesn't imply it is going to touch the filesystem mathrick: but gtktreemodel is not very generic matthias: yeah, I guess it's final argument for not doing it owen, did you look at the patch for named icons in images ? owen: okay, one more question, you said the flags should be reversed to change the NONE behavior. What do you think the default behavior should be? halfline: I think both discard comments and discard translations should be default since comments and translations are only needed if you plan to write the thing out again... matthias: No, not yet halfline: What matthias said halfline: not sure about the lookup map halfline: Preserving translations in particular can be an major performance problem tha tyou might not notice I'm not sure what the lookup map matthias, owen: so if we are optimizing for the read case and not the save case then we should generate the lookup map by default, yea? halfline: how are the keys kept if you don't generate a lookup map ? owen: the lookup map just creates a hash table for the keys (they are normally stored in a list) If the lookup map is a key => value hash to avoid linear list searches, can we just always create it and simplfiy the API? halfline: what owen said owen: If you don't think that the increased memory usage is a big deal, sure I don't have a problem with that. owen: Note, in the case when you are writing a file from scratch you won't ever need the lookup map, however. halfline: well, you need to store the key-value pairs somewhere. if we do away with the list, you will need the map matthias: I think it needs order matthias: you have to keep the list around matthias: Could use a GTree, but that is likely getitng too fancy halfline: I'm not really worried about the memory usage ... if you care about that, I don't think you'll be keeping the GKeyFile objects around. ... an application specific data structure is almost certainly much smaller halfline: if we can only save memory in the rare editing case, I think it is not worth the complication owen, matthias: okay, i'll drop the flag halfline: another simplification I have considered is to remove the legal_start_tags thing. If get_groups() returns the groups in order, halfline: apps can simply check the first group after creating the struct... If we split new() off from load_from_file(), then we have a lot more future flexibility for adding things like g_key_file_set_legal_start_groups() in the future owen: good point, I had considered adding a setter for the start groups Should the setters actually have a GError return? how could they fail? owen: okay that sounds reasonable ok, I will have to stop soon. I wanted to talk quickly about timing. we are already a bit behind schedule for the slush frozen release, but I think it will take at least one more week to get the patches we discussed today in shape and committed so I will aim for a 2.5.x release early next week matthias: Sounds good another thing I wanted to mention is that we still lack a bit wrt to docs for some of the new apis. So if anybody feels like writing something up, that would be great also migration sections similar to what we have for ui manager and combo box and finally I wanted to mention that I committed the icon theme caching today. Please try it... did anyone try out my menu-blinking patch? jrb: sorry, no. But you did get some feedback on the mailing list, didn't you ? matthias: a little bit. I was hoping for comments here before committing matthias: i still have some things i want to discuss regarding the desktop entry stuff, but i can bring it up later I guess halfline: why not ask now while everybody is still here ? matthias: okay. There is code in there that is desktop entry specific regarding handling the encoding of the file halfline: Does it try to handle Legacy-Mixed? owen: yea exactly owen: it basically guess until it see the Encoding key *guesses halfline: is there a way to set the encoding in advance, to declare that a file is UTF-8 ? halfline: Hmm. I wonder how much of that logic we should kill. That guessing is really for handling ancient gnome desktpo files matthias: The spec says that everything before the Encoding field must be ascii, that the Encoding field is required, and that the only value that implementations are required to support is UTF-8 owen: I thought I read that .icon files are required to be UTF-8, from start to end... matthias: Yes. matthias: Later specificatoins that refernece the desktop entry spec tend to explicitely rule out even the faintest possibility of Legacy-Mixed owen: so to use the parser for .icon files, we may want a way to fix the encoding matthias: Rather the reverse. I think if we support Legacy-Mixed at all (dubious) it should be a specific flag to enable the handling owen: possible as well owen: so you think it would be better to just rip out legacy-mixed handling entirely? * owen ponders halfline: Yes. owen: okay halfline: time to move on. KDE has never supported it. halfline: btw, I have a patch to replace gtkiconthemeparser by gdesktopentry in gtk. 1000 lines saved... matthias: cool ok, have to go now. logs will be posted tomorrow Meeting ended October 19, 19:17 EST (23:17 UTC)