Meeting on irc.gnome.org:#gtk-devel Meeting started August 31 2004 17:02 EST (21:02 UTC) In attendence: Jonathan Blandford (jrb), Matthias Clasen (matthias), Owen Taylor (owen), Federico Mena Quintero (federico), Billy Biggs (vektor), Tor Lillqvist (tml), Anders Carlsson (andersca), Soeren Sandmann (ssp) hey tml gokväll should we begin by collecting agenda items ? when's the API freeze date again? federico: plan/2.6 has October 15, 2004 API slush-freeze ah, okay what is a "slush freeze"? is there a definition somewhere of freezes? a "slush freeze" is commonly understood to be a freeze which is not overly strict, ie you can still get api additions in after that date carol: slush means were locking down API, but are willing to make fixes if the API is shown to be problematic in use mclasen: More of an agenda item for next week, but I wanted to mention that I'm working on fituring out a new milestone approach for Pango, so I may propose that for GTK+ if I come up with something I like it sort of makes sense. thanks. owen: I'll note it for next week owen: speaking of pango, are you working on anything related to #97645? federico: Is that the right #? Bug 97645: stream_end signal is never sent sounds more like a gstreamer bug... Presumably 97545? UTR 29? err 97545 federico: No, not personally. Would love if someone tackled it. owen: I know nothing about unicode internals... haven't gotten the book yet TR 29 is on the web... go federico ! federico: everyone just uses the glossary and it is online. the unicode 4.0 book is.... *big*. perfect in-bed reading, NOT http://www.unicode.org/glossary/ tml: do the win32 additions work ok now ? i mean ime and wimp i wondered if we should make the theme the default on win32 ? the ime stuff doesn't really work, it uses the non-wide-char api and thus works for only when the system codepage is a multibyte one. trivial to fix though, just always use the ifdef UNICODE barnches, drop the else branches. tml: BTW, gtkimmodule as XSETTING turns out to be useful for something we are doing here for the GNOME desktop, so assuming that the win32 backend can figure out whether IME is active easily (don't know how that is exposed) that's probably the right way to turn it on still haven't tried wimp owen: does gtkimmodule as XSETTING relate to modules as setting in general, or is that unrelated ? mclasen: Unrelated. it should be possible to figure out, yes. (are you also interested in whether an ime-using input locale is loaded, i.e. switchable to on-the-fly?) tml: Basically, the goal would be to make GTK+ use IME iff. wordpad is using IME at the moment tml: That's my naive view of how it should work tml: GTK+ will be happy switching the input method module on the fly, don't know if their are problems on the win32 end but the input locale switchable per-application. don't know how people in east asia typically work, do they all the time use their local input locale for all apps, or use for instance us english always for some applications Of course another possibility is that GKT+ should just *always* be using the IME apis -- maybe that's how you write an IME aware app in windows tml: Switching the input locale I wouldn't expect to typically involve switching the IM module tml: Presumably when you switch between English and Japanese input for an application the application doesn't switch code paths? hmm... the app does get different windows messages for ime-generated input maybe we should defer the default theme question until we get closer to 2.6... if i run testgtk's entry test, select the gtk "Windows IME" input method, but don't change input locale, nothing changes. if I then switch input locale to japanese, the ime input goes into the entry box. mclasen: Well, possibly we should try switching to wimp by default and see if people complain? But it's up to tml tml: What do you mean by "nothing changes"? without the imime module, the tentative ime input string (or whatever it should be called) is displayed kinda ugly, "stuck" to the screen. with imime, its in the entry box owen: that would be a plan mclasen: Should be a one-line change to do ... just change the "get_setting" function in the win32 backend owen: i mean that no ime activates, the latin chars i type are inserted. tml: Yeah, what ime woudl it activate for latin? tml: I think the only danger of running the im module all the time would be there is some overhead and some possible bugs owen: ok. true. just wanted to make sure there wasn't any misconception that choosing the "windows ime" in gtk would somehow automatically activate some (which?) ime tml: So some sort of check on SM_DBCSENABLED, SM_IMMENABLED is probably right - see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/ime_6wtu.asp tml: Hmm. Actually, I'm planning thinking about for GNOME shutting off the right click menu if the IME is set globally for the desktop via an XSETTING. hmm, i do have all kinds of imes on my English win2k? owen: turing it on in cvs HEAD for win32 for test purposes would make a lot of sense if people actually test gtk+ HEAD/win32. tml, do you build packages for gtk+ HEAD ? nope. should i? tml: yeah, I think by "asian language pack" they mean selecting those components when doing a system install tml: My feeling on the right click menu on windows is that if someone wants to input some other language they'll pick it through the system, not the GTK+ right click menu which works only for GTK+ apps tml: Up to you, but it would certainly increase the chance that people test the theme yeah, but the earlier sentence talks about east asian localized windowses... (where the ui would be in C, J or K.) oh well. tml: I think it's poor editing when they updated that page for win2k ... they just tacked another sentence on. expanders look bad in RTL mode :/ is there any way then for imime to make itself the default if the current input locale is an ime-using one, not otherwise? andersca: fixit! jrb: thats markmc's widget tml: My feeling is that if the user is switching input locales on the fly, we probably don't want to be unloading and loading imime mclasen: huh. it is? jrb: yes tml: Assuming we add this GtkSetting, the win32 backend can completley drive what im module is currently in use, the question is simply what the right behavior is but can it decide at application startup time whether to make itself active or not? mclasen: oh -- I meant TreeView expanders. Same drawing code, though tml: The module isn't queried at app startup time ... that has to be done elsewhere tml: And presumably 'switch to english, start an app, switch to Japanese, try to enter some Japanese' is a common thing for people to do ok. I would assume the correct behaviour would be then to use it when an ime is in use. the fact that the code as submitted was active all the time (language="*") seemns to indicate that this matches user expectation methinks? jrb: also, if you compile with gtk 3.4, the expanders look a bit garbled when expanded jrb: ... with gcc 3.4 ... ssp: yeah. I see that tml: Yeah, it appears to me likely that you could just run it basically all the time without any harm. Though I'm not sure if it would die horribly on a non-IME-enabled win98 since we seem to be a bit topicless today, I'd like to remind us that we should try to make sure that the new api is adaequately documented for 2.6 I think the icon view and goption are currently still a bit weak when it comes to api docs well, we'll just tell win9x users to delete the immodules folder... and things will works like currently, i.e. works fine to input cjk chars but not as elegant tml: Switching off of SM_DBCSENABLED probably is a cheap way to avoid problems, but I guess all we can do is throw it out there and see what happens and we should probably also expand the migration chapter to cover migration from the corresponding libgnomeui widgets to iconview or the various pickers tml: Like the wimp issue, probably the best thing to do is to enable it widely at first and then switch off/fix as necessary. mclasen: goption isn't documented at all... andersca: fixit! mclasen: because I wanted to port gtk over to it first to see if it would need changes mclasen: I will, I've promised owen :) andersca: how is the gtk+ port coming along ? mclasen: speaking of goption, do you think having an option context without a main group is valid? mclasen: I got stuck yesterday pending an answer to the above question andersca: good question. How was the main group different from any other group again ? mclasen: "--help" will show the main group options as "Application options" andersca: but it does make sense to have e.g. an application which has no own options, but uses gtk+ andersca: wouldn't that be an example where a context without a main group would be appropriate ? mclasen: yeah, that's exactly what I'm thinking andersca: so how is the context constructed in your gtk patch ? gtk constructs it inside gtk_parse_args() and adds its option group ? mclasen: yeah mclasen: it also adds gtk_init_with_args and gtk_get_option_group andersca: sounds fine; we should just make sure that --help output looks ok if there is no main group mclasen: yeah owen: btw, about #136280: should gdk/win32 tell gtk about the keyboard layout for all the input locales available (switchable) on the machine? as separate keymap groups? mclasen: this RTL bug is confusing me a little jrb: what is confusing about it ? I'll have to leave soon. Any further topics ? Aug 31 18:00:59 * mclasen leaves his cubicle tml: Errr, sorry, wasn't watching tml: Basically all the keyboards that the user can switch between using a key combination should be listed tml: That is, the canonical example is a russian user with a russian and an english keymap and a key to switch between even if not by key combination, but by manipulating he taskbar's language button...? tml: It's sort of a question of "user intent" ... it would probably be bad if the user happend to add a dvorak layout to the taskbar, forgot about it, then a few months later started wondreing why accelerators were wonky in all his GTK+s. But if you can't tell, I'd say go with the "all layouts" ok tml: I have some ideas what we could do if it turns out that there are problems with all groups ... you could ignore key symbols in other groups if they are already found in the current group ... but that would be adding complexity to already complex code. i guess one potential problem is if somebody for some reason has two (or even three) of qwerty, french and german layouts, that would mean quite many latin chars are on different keys in different layouts tml: yeah, that is what I was saying with dvorak ... if you have french azerty plus qwerty in your keymap list, suddenly you might have Control-q accelerators triggering when you hit control-a OK,just in cas eit isn't obvious, let's declare this meeting adjourned owen: I'll fix goption to support contexts without a main group and commit Aug 31 18:29:34 * andersca assumes he doesn't need commit approval for that andersca: Sounds good Meeting ended August 31, 18:32 EST (22:32 UTC)