Re: Command Buffer for Accessing Menus
On Jun 12, 2007, at 9:36 PM, ricardo colon wrote: > For example, let's say Ardour has a menu called "Automation". > You would type something like Ctrl-X and then type in "Automation". > The Automation menu would directly pop-up. You wouldn't have to go > through Tools -> Midi -> Automation or anything like that. > > "Automation" would be the full-length keyword. To make things quicker, > you could have a "full name" and maybe a shorter name. So for example, > you could type "Ctrl-X automation" or "Ctrl-X atm". and it would mean > the same thing. > > Even better, you could assign common command buffer commands to a > single key. So you could bind "Ctrl-X atm" to Ctrl-F1 or something > similar. Perhaps i'm missing something. Provided the application sets up its mnemonics correctly, how is your proposal superior to what we already have? Press Alt Press t to open Tools menu Press m to open Midi submenu Press a to open Automation submenu Press whatever key corresponds to the mnemonic on what you want there Release Alt -- Doing a good job around here is like wetting your pants in a dark suit; you get a warm feeling, but no one notices. -- unknown ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Damon Chaplin wrote: >> I think its quite important here to not repeat one of the >> the most obvious mistakes of glade/libglade, swapping the >> signal based on the fact that an "object" was specified >> is confusing - it also rules out the use case of specifying >> a signal that is not swapped & has an object user_data. > > Back in the GTK+ 1.x days I think gtk_signal_connect_object() used to > automatically swap the callback arguments. There wasn't any "swap" > option. > > So calling it "one of the most obvious mistakes" is a bit harsh! It might make sense to do the same for gtkbuilder, since libglade does the same when you set the object attribute, that'd make it easier to migrate from the older formats. Or just make the conversion scripts insert swapped="yes" when converting an old libglade file. Johan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
Kristian Rietveld wrote: > [snip] > In the GTK+ source code you will find a test app testing all of the > above methods in gtk+/tests/testtooltips.c. There are examples for > simple tooltips on buttons (also insensitive buttons!), tooltips on > GtkTreeView rows, tooltips on GtkTextView tags and a small example with > tooltips on specific areas of a GtkDrawingArea. (Yes, I know the tree > view example is a little broken -- it will be fixed RSN). > Tooltips do not show at all here. Sometimes, when I put mouse over a colored rectangle or label text, and then move mouse away, tooltip shows up for a fraction of second. It's fresh Gtk from today svn. And I didn't break it! Selection in the treeview is blue, so it indeed gets focus. Tooltips are working in gtk-demo's "main application window". Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>: > Kalle Vahlman wrote: > > [snip philosophy] > > [1] though I don't really agree on widgets setting colors at all, > > regardless the fact that it then possibly won't look good with older > > themes (depending on what colors you can use). > > > > If you are really interested, get a fresh tarball of gtksourceview > and see what a style scheme is. Perhaps then you'll stop convicting > me of breaking user themes, expectations, and whatnot. These > talks about how things should be in general are nice but are not > to the point. Sure, but the basic issue was "should widgets set their name in the constructor"[1] Let's brew it down like this: Me: njet. You: da. I think we are done here :) [1] Regardless of what it is used for, I don't see style schemes requiring that. In fact, I see benefit in making the style scheme be the identifying one (not the widget) so it could be trivially applyable to multiple widgets... But whatever. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Menu groups vs. use of separators
On 6/14/07, Alex Jones <[EMAIL PROTECTED]> wrote: > On Thu, 2007-06-14 at 08:15 +0200, Sven Neumann wrote: > > Hi, > > > > On Thu, 2007-06-14 at 03:26 +0100, Alex Jones wrote: > > > > > I've been looking at how Rhythmbox allows plugins to manipulate menus > > > (via UI manager magic), and it dawned on me that there is no way to > > > separate these out visually, other than to attempt to guess whether > > > there should be a separator placed above and/or below what you're trying > > > to insert. Of course, what I really want GTK to do is to insert > > > separators *between* groups of menu items. Having this kind of ability > > > would greatly simplify much goofy logic that is currently in place in a > > > lot of applications to decide where separators should be placed. > > > > You can already do that using GtkUIManager. Your application should add > > placeholders for the groups that you described. Then add separators > > between the placeholders. Plug-ins can then register in the placeholder > > items. The smart separators will only be shown when needed. > > OK, but I need to know how many groups are needed here in advance. I'm > not sure this solves the problem, because when I go to programatically > add another group to the end of the list I have to decide whether there > is a separator already at the end or not. > -- That is the bit that smart separators save you from. They hide when they end up next to the edge of the menu or next to another separator. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Kalle Vahlman wrote: [snip philosophy] > [1] though I don't really agree on widgets setting colors at all, > regardless the fact that it then possibly won't look good with older > themes (depending on what colors you can use). > If you are really interested, get a fresh tarball of gtksourceview and see what a style scheme is. Perhaps then you'll stop convicting me of breaking user themes, expectations, and whatnot. These talks about how things should be in general are nice but are not to the point. Could not resist, sorry. Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>: > Kalle Vahlman wrote: > > Is there a particular reason to set the name in _init() rather than in > > _set_cursor_colors()? It would avoid setting it completely if using > > Gtk+ >=2.11.3 > > Code was written before Gtk+ >= 2.11.3. ...with a chisel to a stone I gather ;) > > and since it does nothing(?) if the custom colors are > > not set... > > > > Also, why is it neccessary when the colors are not set explicitly? > > Isn't the class name as good as any for setting default values in > > themes? > > What's necessary? Let's not consider funny cases when nothing changed, > think white cursor and white text color and black background in a usual > black-on-white gtk theme (people actually do use dark themes, it's not > some academic exercise about how to override theme colors). I meant, why does the widget need to have the unique name even if the cursor colors are not set? Maybe I missed that but I didn't see it set anywhere in the initialization code so the unique name matches to exactly nothing until someone sets it. > >> The GtkSourceView code (and code above) was an example > >> of code which uses unique widget name to modify style property, > >> since you didn't seem to believe it is possible and may be > >> needed. > > > > I never said it wouldn't be needed. I'm just saying that there is no > > reason to do it in construction stage, > > You were talking about class matching and whatnot, so I got > that impression. Anyway, one possible reason is that constructor > and init() are natural places for things which are done once for > whole life of the widget. Another reason is that one may still > change the name if he knows what he's doing (GtkBuilder doesn't > and it's what sucks). Dunno, it just happened so. Now, "If you want > the widget to be used with GtkBuilder you must not set widget > name until after construction. Why? No reason really, just because." > It's silly. Because the user gave it a name in the xml and would possibly like that to be matchable from a gtkrc? If the application explicitly sets the cursor color, well, then it's bye-bye for the end-user theme I guess... > > since it will not give you > > anything over matching by class. > > That setting is *per-widget*, not per-class. Unless it's not set, which means either the default value or the value from any parsed gtkrc. Which was my point. > > If you need to hack styles in later, > > you can set the name then and hope the user doesn't go and change it > > afterwards. Also you can hope that the user didn't want to customize > > the theming of that widget by his own account and get angry at you > > since the widget changes it's name making it impossible... > > So there are possible problems (of course), so I shouldn't mind > one more possible complication? Note that this latter complication > is not related to theme business (as opposed to user changing styles > manually and breaking things), it's just some strange function > call in a place seemingly unrelated to the theme business. "manually" as in gtkrc? I consider that the authority when it comes to what style settings should be obeyed, if the application overrides that... well. I guess it's your application. For the record, I do understand[1] why the unique names and styles are used. But since it is very error prone and unfriendly to themes when done *inside* widgets (or even applications), I don't think it's worth blocking a natural expectation of the user of GUI editors; that the "Name" field in the editor will really be the name of the widget which you can use in gtkrc:s for your own theming options. If you now understand my POV (that's all I'm after), we could just stop here (it's not like this is really constructive anymore ;) [1] though I don't really agree on widgets setting colors at all, regardless the fact that it then possibly won't look good with older themes (depending on what colors you can use). -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ compile
On Thu, 2007-06-14 at 05:04 -0700, Jeevan wrote: > Dear all, > Here I am trying to run a simple GUI program using Gtk+.. > I am getting error as follows: This list is for development of Gtk+ itself, the list for developments using Gtk+ is [EMAIL PROTECTED] > linux:~ # gcc base.c -o base 'pkg-config --cflags --libs gtk+-2.0' > gcc: pkg-config --cflags --libs gtk+-2.0: No such file or directory You should use `pkg-config ...` (note the backticks instead of the single quotes). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
> A new API called "GtkTooltip" replaces an API called "GtkTooltips"? Seems > like that could become very confusing.. especially when using two or more > GtkTooltips. Couldn't you have came up with something a little more > imaginative? :) Perhaps "GtkTooltipEx"? GtkTooltippr? Haw haw. :-) - Jeff -- Ubuntu Live 2007: Portland, OR, USA http://www.ubuntulive.com/ "Laughter is a force for democracy." - John Cleese ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Menu groups vs. use of separators
On Thu, 2007-06-14 at 08:15 +0200, Sven Neumann wrote: > Hi, > > On Thu, 2007-06-14 at 03:26 +0100, Alex Jones wrote: > > > I've been looking at how Rhythmbox allows plugins to manipulate menus > > (via UI manager magic), and it dawned on me that there is no way to > > separate these out visually, other than to attempt to guess whether > > there should be a separator placed above and/or below what you're trying > > to insert. Of course, what I really want GTK to do is to insert > > separators *between* groups of menu items. Having this kind of ability > > would greatly simplify much goofy logic that is currently in place in a > > lot of applications to decide where separators should be placed. > > You can already do that using GtkUIManager. Your application should add > placeholders for the groups that you described. Then add separators > between the placeholders. Plug-ins can then register in the placeholder > items. The smart separators will only be shown when needed. OK, but I need to know how many groups are needed here in advance. I'm not sure this solves the problem, because when I go to programatically add another group to the end of the list I have to decide whether there is a separator already at the end or not. -- Alex Jones http://alex.weej.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
On 6/12/07, Kristian Rietveld <[EMAIL PROTECTED]> wrote: > On Sun, Jun 10, 2007 at 10:38:44AM +0200, Murray Cumming wrote: > > There's also a new GtkTooltip object. Could we have some more information > > about how this should be used and if it replaces any existing API, please? > > Sure ;) As Matthias pointed out in one of his other mails, GTK+ 2.12 > has a brand-new API for doing tooltips, replacing the aging GtkTooltips > object. There are several ways for showing tooltips using the new API, > increasing in complexity as the complexity of the wished tooltip > increases: A new API called "GtkTooltip" replaces an API called "GtkTooltips"? Seems like that could become very confusing.. especially when using two or more GtkTooltips. Couldn't you have came up with something a little more imaginative? :) -- mvh Björn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
On Tue, 2007-06-12 at 13:59 +0200, Kristian Rietveld wrote: > 2. When you need a tooltip with a little more fancy contents, like > adding an image, or you want the tooltip to have different contents > per GtkTreeView row or cell, you will have to do a little more work: > > - Set the has-tooltip property on GtkWidget to TRUE, this will > make GTK+ monitor the widget for motion and related events > which are needed to determine when and where to show a tooltip. I still think this is unnecessary and clutters the API - it can be determined automatically from the other settings. Can't we get rid of it? Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Damon Chaplin wrote: > On Wed, 2007-06-13 at 11:49 -0400, Tristan Van Berkom wrote: > >> Anyway, my point here is not wrt code that exists already in Gtk+, >> I am of the opinion that GContainer iface is "missing", and that >> objects in general use other objects in general, and in that process >> of ownership, packing properties are an essential thing. > > Yes, generic support for packing properties will be needed for any > future GtkCanvas widget as well (for packing items inside each other). Not really, GtkCanvas can just define it's own custom tags where it controls the relation between the canvas and its items. What Tristan wants is a way to override and introspect these properties. Johan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Wed, 2007-06-13 at 11:49 -0400, Tristan Van Berkom wrote: > Anyway, my point here is not wrt code that exists already in Gtk+, > I am of the opinion that GContainer iface is "missing", and that > objects in general use other objects in general, and in that process > of ownership, packing properties are an essential thing. Yes, generic support for packing properties will be needed for any future GtkCanvas widget as well (for packing items inside each other). Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Thu, 2007-06-14 at 12:42 +0300, [EMAIL PROTECTED] wrote: > So, I'm asking: Why not include something like "set widget name" option > into glade and xml-file, or separate property for the name to be set?? > Those widgets that have this flag set will have gtk_widget_set_name called, > other do not (name is just a internal reference, like a variable name in C). > By default this would be off (since most widgets are certainly not special > ones, you are not calling gtk_widget_set_name for each widget if you write > the UI by hand, do you...) In Glade-2 for code generation it was a project-wide option, "Set Widget Names", and the default was FALSE (since few people use them). If it was up to me I'd probably make it an optional GtkBuilder setting, and default to FALSE again. Though it's not a big deal. Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Kalle Vahlman wrote: > 2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>: >> Kalle Vahlman wrote: >> > 2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>: >> >> Kalle Vahlman wrote: >> >> > 2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>: >> >> >> Set widget name in constructor or init(), then create this widget >> >> with >> >> >> GtkBuilder. >> >> >> Yeah, "semi-broken". >> >> > >> >> > Why is that preferrable over matching by the widget class name? >> >> > >> >> See >> >> >> http://svn.gnome.org/viewcvs/gtksourceview/trunk/gtksourceview/gtksourcestylescheme.c?view=markup >> >> >> >> >> >> for cursor color thing, set_cursor_colors() function. >> > >> > Which part of it breaks due GtkBuilder? I don't see GtkSourceView >> > setting it's name (nor the cursor colors) in the constructor, which >> > was the primary concern you brought up. >> >> Oh well, >> http://mooedit.sourceforge.net/hg/moo/?f=4c33c8446db7;file=moo/mooedit/mootextview.c >> >> >> see moo_text_view_init. What does it change? > > Is there a particular reason to set the name in _init() rather than in > _set_cursor_colors()? It would avoid setting it completely if using > Gtk+ >=2.11.3 Code was written before Gtk+ >= 2.11.3. > and since it does nothing(?) if the custom colors are > not set... > > Also, why is it neccessary when the colors are not set explicitly? > Isn't the class name as good as any for setting default values in > themes? What's necessary? Let's not consider funny cases when nothing changed, think white cursor and white text color and black background in a usual black-on-white gtk theme (people actually do use dark themes, it's not some academic exercise about how to override theme colors). > >> The GtkSourceView code (and code above) was an example >> of code which uses unique widget name to modify style property, >> since you didn't seem to believe it is possible and may be >> needed. > > I never said it wouldn't be needed. I'm just saying that there is no > reason to do it in construction stage, You were talking about class matching and whatnot, so I got that impression. Anyway, one possible reason is that constructor and init() are natural places for things which are done once for whole life of the widget. Another reason is that one may still change the name if he knows what he's doing (GtkBuilder doesn't and it's what sucks). Dunno, it just happened so. Now, "If you want the widget to be used with GtkBuilder you must not set widget name until after construction. Why? No reason really, just because." It's silly. > since it will not give you > anything over matching by class. That setting is *per-widget*, not per-class. > If you need to hack styles in later, > you can set the name then and hope the user doesn't go and change it > afterwards. Also you can hope that the user didn't want to customize > the theming of that widget by his own account and get angry at you > since the widget changes it's name making it impossible... So there are possible problems (of course), so I shouldn't mind one more possible complication? Note that this latter complication is not related to theme business (as opposed to user changing styles manually and breaking things), it's just some strange function call in a place seemingly unrelated to the theme business. > > [snip] > >> The widget does >> *not* violate any Gtk rules, it uses properties and whatnot. >> It uses widget name just as docs say widget name is intended >> to be used. And so on and so forth. >> >> Or let's get back to "gtk-tooltips". No, symbolic colors >> won't solve it as long as it's not mandatory for a theme to have >> some predefined "tooltip" color, and it will never be the case. > > *Nothing* is mandatory in a theme. In fact, you can run GTK+ without a > theme at all! Making widgets that won't work in that case is (ie. > without specific style set) is just plain wrong. Who makes such widgets? Is it relevant? > They may look like > shit, but that's hardly the point, they still should be usable (even > if it means the cursor color won't be pink, but matches the foreground > color...). > > I think that GTK+ should have a stock-item style database for colors > too, so one could finally start theming widgets a bit more sensibly > (but that's really some other thread of discussion). Well, if documented usage of gtk_widget_set_name() will die because we get API and everything for everything, it will be great. As well it would be great if everything was great. > >> If you write a widget which looks like a tooltip, you can't use >> it with GtkBuilder, very simple. > > You mean you can't use it if you want the theme's colors on it, which > is unfortunate (but fixable by making the tooltip window a derived > class I think?). You can't use it with GtkBuilder (without resetting name manually after construction) if you want it to be yellow (i.e. have the tooltip color from the theme). And no, not a window (derivation has nothing to do with it, absolutely). gedit message area th
Re: GtkBuilder Public API - Last call
> I think its quite important here to not repeat one of the > the most obvious mistakes of glade/libglade, swapping the > signal based on the fact that an "object" was specified > is confusing - it also rules out the use case of specifying > a signal that is not swapped & has an object user_data. Back in the GTK+ 1.x days I think gtk_signal_connect_object() used to automatically swap the callback arguments. There wasn't any "swap" option. So calling it "one of the most obvious mistakes" is a bit harsh! Damon ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Steve Frécinaux wrote: > On Thu, 2007-06-14 at 10:41 -0300, Johan Dahlin wrote: > >> Let's use this xml attributes for the signal tag; >> >> name: signal name >> handler: handler to connect the signal to >> after: optional, boolean if True, set flags to G_CONNECT_AFTER >> swapped: optional, boolean if True, set flags to G_CONNECT_SWAPPED >> object: optional, if set use g_signal_connect_object > > I still don't understand how "swapped" is relevant in the XML context > instead of in the C code actually connecting the handler. It looks like > implementation detail to me, that should not be enforced by the XML > file... The same applies for "after" and "object". > > Do someone has a real-life example for when it is useful ? It's the same use case as g_signal_connect_after, it's occasionally useful to make sure that a handler is executed after all other handlers. For instance you might want to play a movie which is draw on a drawing area, but only start the playback after it's realized. Johan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Morten Welinder wrote:
>> user_type and user_data which I proposed doesn't make too much sense,
>> it's
>> also difficult to support since you can't (AFAICT) use a GValue as
>> user data.
>
> It would be marginally useful for providing constant user data like...
>
> * Strings: "oink"
> * Translated strings: _("Moo!")
> * Integers: GINT_TO_POINTER(12)
>
> Having integer arguments saves you a function if you have, for example,
> "Up"
> and "Down" buttons that are handled almost identically.
Right, useful but not a blocker IMO.
I'll open a bug to add support for this after landing the initial version of
GtkBuilder.
Johan
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: gtk+ compile
On Thu, 2007-06-14 at 05:04 -0700, Jeevan wrote: > Dear all, > Here I am trying to run a simple GUI program using Gtk+.. this list is for developing gtk+, not developing with gtk+. you want gtk-list or gtk-app-devel-list. > I am getting error as follows: > > linux:~ # gcc base.c -o base 'pkg-config --cflags --libs gtk+-2.0' > gcc: pkg-config --cflags --libs gtk+-2.0: No such file or directory you have to use backticks: ` ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Thu, 14 Jun 2007, Johan Dahlin wrote: > Tim Janik wrote: >> there could conceivably be new flags in the future. also, >> "object" is different from "swapped". the former should use >> g_signal_connect_object which needs a GObject argument and >> auto-disconnects the signal handler if the object argument >> is disposed. the later also works for void* pointers. > > Oh, I knew I missed something. > > Let's use this xml attributes for the signal tag; > > name: signal name > handler: handler to connect the signal to > after: optional, boolean if True, set flags to G_CONNECT_AFTER > swapped: optional, boolean if True, set flags to G_CONNECT_SWAPPED > object: optional, if set use g_signal_connect_object > > user_type and user_data which I proposed doesn't make too much sense, it's > also difficult to support since you can't (AFAICT) use a GValue as user data. > > g_signal_connect_object does not provide a way to send in user data so it > conflicts with the user data which may be passed in to > gtk_builder_connect_signals. well, to be more precise, g_signal_connect_object hardcodes the assumption that user_data is_a GObject*. > Not a too big deal I guess, it just needs to be > documented. > > Johan > --- ciaoTJ ___ 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 17:39 -0500, Sean Middleditch wrote: > Just a reminder that : is the separator used in the PATH environment > variable, and is thus a poor choice for use in directories. > > In all honesty, if the intended use case for reading the directory info > is for FUSE and GVFS, I think it would be a lot cleaner to just put some > kind of user-friendly name in ~/.mounts/, and then create a ~/.mountrc > config file that maps the names to mount parameters which the FUSE fs > and GVFS can use to recreate the mount points. Basically, it'd just be > a per-user fstab replacement. I want to make sure this takes NFS mounted home directories into consideration. I think perhaps ~ is a very poor choice of location for this. > > Add in a few CLI utils to call mount with the right parameters for > mounts in ~/.mountrc, and you'll have a pretty solid system for both > modern GUI, legacy GUI, and CLI users. > > >> 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. ___ 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 Tue, June 12, 2007 3:51 pm, Jerome Haltom wrote: > I want to make sure this takes NFS mounted home directories into > consideration. I think perhaps ~ is a very poor choice of location for > this. Why would ~ be a poor choice? The GVFS system would not be responsible for mounting home directories at all, and I'm fairly sure you can mount other file-systems on top of directories within an NFS mount without too much worry. If the NFS mount goes down you'd have trouble, but that's sort of a given anyway. -- Sean Middleditch AwesomePlay Productions, Inc. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Command Buffer for Accessing Menus
Hello GTKers. I apologize for the cross post. I confused the "people who develop with GTK" mailing list for the "people that develop GTK" mailing list. I posted the following email to the Ardour(http://ardour.org) development group. One of the replies suggested that maybe my feature request is better suited at the GTK level. So here I am. Here's the email I sent to the Ardour devel mailing list. Tell me what you think about such a feature being in GTK. -- Many times, I feel that having to drag over a mouse to a drop down menu and move down to the correct menu takes too much time and distracts me. By the time I reach the menu, my mind has drifted off to something else for a moment. I was thinking it might be cool to have something similar to Emacs command buffer. This buffer would be used for directly accessing menus. But instead of using obscure keyboard shortcuts, it would use keywords. For example, let's say Ardour has a menu called "Automation". You would type something like Ctrl-X and then type in "Automation". The Automation menu would directly pop-up. You wouldn't have to go through Tools -> Midi -> Automation or anything like that. "Automation" would be the full-length keyword. To make things quicker, you could have a "full name" and maybe a shorter name. So for example, you could type "Ctrl-X automation" or "Ctrl-X atm". and it would mean the same thing. Even better, you could assign common command buffer commands to a single key. So you could bind "Ctrl-X atm" to Ctrl-F1 or something similar. Not only would you be able to access menus in the drop down list at the top of the screen, but you could also directly access sub-menus as well(instead of having to click through 3 or 4 menus to get where you want). In the beginning, you could have this work for the standard menus. But you could also have user-defined keywords for things like plugins. Imagine if you had a plugin called "reverb". You'd highlight a portion of the audio, hit "Ctrl-X reverb" and it would immediately bring up the reverb plugin (with the selected audio as input if you want to). Anyway, that's the gist of my idea. I think keywords would be very intuitive for people and would work well across many platforms. You wouldn't even have to worry about keyboard shortcuts convention across different platforms. And I think it's much more efficient than using the mouse in many cases. - This could even work for something like GIMP. Highlight a selection, type "Ctrl-x smudge" and the Smudge menu might appear with the current region already selected as input. In addition, you might be able to directly access script-fu plugins. In any case, I'm not sure where such code would go, but it'd definitely be a killer feature. I'm sure there's probably some way to hack up something to emulate this kind of behavior. But I think it'd be great if there was somebkind of pluggable GTK architecture that all apps could support by providing the right hooks. Maybe the command buffer portion doesn't need to be mandatory. It could just be one of many different views or interfaces that could be used. For example, you could use a Wii remote :-) Anyway, Hope I'm not wasting anyone's time. Thanks. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk+ compile
Dear all, Here I am trying to run a simple GUI program using Gtk+.. I am getting error as follows: linux:~ # gcc base.c -o base 'pkg-config --cflags --libs gtk+-2.0' gcc: pkg-config --cflags --libs gtk+-2.0: No such file or directory base.c:1:21: gtk/gtk.h: No such file or directory base.c: In function `main': base.c:6: error: `GtkWidget' undeclared (first use in this function) base.c:6: error: (Each undeclared identifier is reported only once base.c:6: error: for each function it appears in.) base.c:6: error: `window' undeclared (first use in this function) base.c:10: error: `GTK_WINDOW_TOPLEVEL' undeclared (first use in this function) Thank you very much in advance.. Regards JivanDear all, Here I am trying to run a simple GUI program using Gtk+.. I am getting error as follows: linux:~ # gcc base.c -o base 'pkg-config --cflags --libs gtk+-2.0' gcc: pkg-config --cflags --libs gtk+-2.0: No such file or directory base.c:1:21: gtk/gtk.h: No such file or directory base.c: In function `main': base.c:6: error: `GtkWidget' undeclared (first use in this function) base.c:6: error: (Each undeclared identifier is reported only once base.c:6: error: for each function it appears in.) base.c:6: error: `window' undeclared (first use in this function) base.c:10: error: `GTK_WINDOW_TOPLEVEL' undeclared (first use in this function) Thank you very much in advance.. Regards Jivan -- View this message in context: http://www.nabble.com/gtk%2B-compile-tf3921352.html#a8812 Sent from the Gtk+ - Dev - General mailing list archive at Nabble.com. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
> user_type and user_data which I proposed doesn't make too much sense, it's
> also difficult to support since you can't (AFAICT) use a GValue as user data.
It would be marginally useful for providing constant user data like...
* Strings: "oink"
* Translated strings: _("Moo!")
* Integers: GINT_TO_POINTER(12)
Having integer arguments saves you a function if you have, for example, "Up"
and "Down" buttons that are handled almost identically.
M.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Thu, 2007-06-14 at 10:41 -0300, Johan Dahlin wrote: > Let's use this xml attributes for the signal tag; > > name: signal name > handler: handler to connect the signal to > after: optional, boolean if True, set flags to G_CONNECT_AFTER > swapped: optional, boolean if True, set flags to G_CONNECT_SWAPPED > object: optional, if set use g_signal_connect_object I still don't understand how "swapped" is relevant in the XML context instead of in the C code actually connecting the handler. It looks like implementation detail to me, that should not be enforced by the XML file... The same applies for "after" and "object". Do someone has a real-life example for when it is useful ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Tim Janik wrote: > On Wed, 13 Jun 2007, Johan Dahlin wrote: > >> Johan Dahlin wrote: >>> Christian Persch wrote: Hi; > typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder, >const gchar *handler_name, >GObject *object, >const gchar *signal_name, >GObject *connect_object, >gboolean after, >gpointer user_data); Could we have "GConnectFlags flags" instead of "gboolean after" here, so this could also support swapped handlers in future? >>> >>> This was copied more or less directly from libglade, there's a certain >>> advantage of making this compatible with the existing code. >>> >> >> Well, actually swapped handlers are supported, using the object >> attribute, eg: >> >> >> >> >> >> >>> It definitely makes sense to support GConnectFlags though. >> >> I thought there were other flags apart from after and swapped, so this is >> not true, right? > > there could conceivably be new flags in the future. also, > "object" is different from "swapped". the former should use > g_signal_connect_object which needs a GObject argument and > auto-disconnects the signal handler if the object argument > is disposed. the later also works for void* pointers. Oh, I knew I missed something. Let's use this xml attributes for the signal tag; name: signal name handler: handler to connect the signal to after: optional, boolean if True, set flags to G_CONNECT_AFTER swapped: optional, boolean if True, set flags to G_CONNECT_SWAPPED object: optional, if set use g_signal_connect_object user_type and user_data which I proposed doesn't make too much sense, it's also difficult to support since you can't (AFAICT) use a GValue as user data. g_signal_connect_object does not provide a way to send in user data so it conflicts with the user data which may be passed in to gtk_builder_connect_signals. Not a too big deal I guess, it just needs to be documented. Johan ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: The new tooltips API in 5 minutes [Was: Re: Whats coming in GTK+ 2.12, continued]
On 6/12/07, Kristian Rietveld <[EMAIL PROTECTED]> wrote: > On Sun, Jun 10, 2007 at 10:38:44AM +0200, Murray Cumming wrote: > > There's also a new GtkTooltip object. Could we have some more information > > about how this should be used and if it replaces any existing API, please? > > Sure ;) As Matthias pointed out in one of his other mails, GTK+ 2.12 > has a brand-new API for doing tooltips, replacing the aging GtkTooltips > object. There are several ways for showing tooltips using the new API, > increasing in complexity as the complexity of the wished tooltip > increases: [blah blah] Would be nice if this could be in some the tutorial or something. -- my place on the web: floss-and-misc.blogspot.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>: > Kalle Vahlman wrote: > > 2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>: > >> Kalle Vahlman wrote: > >> > 2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>: > >> >> Set widget name in constructor or init(), then create this widget > >> with > >> >> GtkBuilder. > >> >> Yeah, "semi-broken". > >> > > >> > Why is that preferrable over matching by the widget class name? > >> > > >> See > >> http://svn.gnome.org/viewcvs/gtksourceview/trunk/gtksourceview/gtksourcestylescheme.c?view=markup > >> > >> for cursor color thing, set_cursor_colors() function. > > > > Which part of it breaks due GtkBuilder? I don't see GtkSourceView > > setting it's name (nor the cursor colors) in the constructor, which > > was the primary concern you brought up. > > Oh well, > http://mooedit.sourceforge.net/hg/moo/?f=4c33c8446db7;file=moo/mooedit/mootextview.c > see moo_text_view_init. What does it change? Is there a particular reason to set the name in _init() rather than in _set_cursor_colors()? It would avoid setting it completely if using Gtk+ >=2.11.3 and since it does nothing(?) if the custom colors are not set... Also, why is it neccessary when the colors are not set explicitly? Isn't the class name as good as any for setting default values in themes? > The GtkSourceView code (and code above) was an example > of code which uses unique widget name to modify style property, > since you didn't seem to believe it is possible and may be > needed. I never said it wouldn't be needed. I'm just saying that there is no reason to do it in construction stage, since it will not give you anything over matching by class. If you need to hack styles in later, you can set the name then and hope the user doesn't go and change it afterwards. Also you can hope that the user didn't want to customize the theming of that widget by his own account and get angry at you since the widget changes it's name making it impossible... > >> For non-unique name, try > >> to get tooltips color on your widget without "gtk-tooltips" name. > > > > I think this: > > > > http://mail.gnome.org/archives/usability/2007-June/msg00027.html > > > > is by far a better solution to this problem than fiddling with the > > widget names. > > > > Let's not get caught in the "support old crappy ways in new API since > > someone might have written some software depending on that"-thing that > > some operating systems are guilty of. We are not breaking anything > > here that wouldn't be broken anyway with the current method. And > > people *do* use custom widgets with libglade, at least I do. It just > > needs a little push from the application side to work, which is true > > with the gtk-tooltips issue too (just name the widget after > > construction in the application and it'll work). > > > > Yep, there is no real break (as in existing code won't break, > since existing code doesn't use GtkBuilder); and in any case all those > bugs are not hard to fix/workaround. Still, why do I need to change > my code to make widget usable with GtkBuildable? > The widget does > *not* violate any Gtk rules, it uses properties and whatnot. > It uses widget name just as docs say widget name is intended > to be used. And so on and so forth. > > Or let's get back to "gtk-tooltips". No, symbolic colors > won't solve it as long as it's not mandatory for a theme to have > some predefined "tooltip" color, and it will never be the case. *Nothing* is mandatory in a theme. In fact, you can run GTK+ without a theme at all! Making widgets that won't work in that case is (ie. without specific style set) is just plain wrong. They may look like shit, but that's hardly the point, they still should be usable (even if it means the cursor color won't be pink, but matches the foreground color...). I think that GTK+ should have a stock-item style database for colors too, so one could finally start theming widgets a bit more sensibly (but that's really some other thread of discussion). > If you write a widget which looks like a tooltip, you can't use > it with GtkBuilder, very simple. You mean you can't use it if you want the theme's colors on it, which is unfortunate (but fixable by making the tooltip window a derived class I think?). > I don't think it's a big deal because we won't get to the level > of doing everything in glade anyway. Still, it's a weird thing. What is weird is that widgets should be style neutral but aren't. That's a property of the current style system though, I guess. > Anyway, let us stop. Indeed, at least for this thread. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Hi,
Lainaus Yevgen Muntyan <[EMAIL PROTECTED]>:
[clip]
>
> Yes you can set the name after construction.
>
> gtk_builder_build_stuff();
> widget1 = gtk_builder_lookup ("foo");
> gtk_widget_set_name (widget1, "gtk-tooltips");
> /* oops, forgot to set up widget2 after adding it in glade,
> since we set all the properties in glade, don't we? */
>
> IMHO, it's silly.
>
> I don't think it's a big deal because we won't get to the level
> of doing everything in glade anyway. Still, it's a weird thing.
> Anyway, let us stop. People are fine with this, good.
> No need to tell how to work it around, it's clear how to
> work it around; and no need to explain how it's wrong to
> do these nasty things with styles, because it's *not* wrong
> (it sucks one has to do things like that, indeed).
What about the opposite scenario: Application developer wants that
some widgets designed by glade need to have their names set, in order
to be themed in a special way. If the builder won't set the names,
then developer ends up fetching the pointers and set the names by hand...
just like in your example.
So, I'm asking: Why not include something like "set widget name" option
into glade and xml-file, or separate property for the name to be set??
Those widgets that have this flag set will have gtk_widget_set_name called,
other do not (name is just a internal reference, like a variable name in C).
By default this would be off (since most widgets are certainly not special
ones, you are not calling gtk_widget_set_name for each widget if you write
the UI by hand, do you...)
-Markku-
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Wed, 13 Jun 2007, Johan Dahlin wrote:
Christian Persch wrote:
Hi;
Le mercredi 13 juin 2007 à 11:07 -0300, Johan Dahlin a écrit :
Is there are reason to prefer glade_xml_signal_connect[data] to the
connect_signals() api? Assuming we add a user data argument to
connect_signals, see separate discussion.
I don't think we need a separate connect_data if we add that user_data
argument. CONNECT_SWAPPED still needs to be handled in this case,
however.
I can't see a use case where sending in a user_data and CONNECT_SWAPPED at
the same time makes sense. Do you know of one?
"swapped" *only* makes sense in connection with user_data on signal
connections. e.g.:
FILE *file = fopen ("/tmp/foo", "w");
g_signal_connect_swapped (button, "destroy", G_CALLBACK (fclose), file);
for GObject*s, you need g_signal_connect_object to disconnect the handler
when either obejct dies (window or button):
g_signal_connect_object (button, "clicked", G_CALLBACK (gtk_widget_destroy),
window, G_CONNECT_SWAPPED);
Johan
---
ciaoTJ___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
On Wed, 13 Jun 2007, Johan Dahlin wrote: > Johan Dahlin wrote: >> Christian Persch wrote: >>> Hi; >>> typedef void (*GtkBuilderConnectFunc) (GtkBuilder *builder, const gchar *handler_name, GObject *object, const gchar *signal_name, GObject *connect_object, gboolean after, gpointer user_data); >>> Could we have "GConnectFlags flags" instead of "gboolean after" here, so >>> this could also support swapped handlers in future? >> >> This was copied more or less directly from libglade, there's a certain >> advantage of making this compatible with the existing code. >> > > Well, actually swapped handlers are supported, using the object attribute, eg: > > > > > > >> It definitely makes sense to support GConnectFlags though. > > I thought there were other flags apart from after and swapped, so this is > not true, right? there could conceivably be new flags in the future. also, "object" is different from "swapped". the former should use g_signal_connect_object which needs a GObject argument and auto-disconnects the signal handler if the object argument is disposed. the later also works for void* pointers. > > Johan --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Kalle Vahlman wrote:
> 2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>:
>> Kalle Vahlman wrote:
>> > 2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>:
>> >> Set widget name in constructor or init(), then create this widget
>> with
>> >> GtkBuilder.
>> >> Yeah, "semi-broken".
>> >
>> > Why is that preferrable over matching by the widget class name?
>> >
>> See
>> http://svn.gnome.org/viewcvs/gtksourceview/trunk/gtksourceview/gtksourcestylescheme.c?view=markup
>>
>>
>> for cursor color thing, set_cursor_colors() function.
>
> Which part of it breaks due GtkBuilder? I don't see GtkSourceView
> setting it's name (nor the cursor colors) in the constructor, which
> was the primary concern you brought up.
Oh well,
http://mooedit.sourceforge.net/hg/moo/?f=4c33c8446db7;file=moo/mooedit/mootextview.c
see moo_text_view_init. What does it change?
The GtkSourceView code (and code above) was an example
of code which uses unique widget name to modify style property,
since you didn't seem to believe it is possible and may be
needed.
>
>> For non-unique name, try
>> to get tooltips color on your widget without "gtk-tooltips" name.
>
> I think this:
>
> http://mail.gnome.org/archives/usability/2007-June/msg00027.html
>
> is by far a better solution to this problem than fiddling with the
> widget names.
>
> Let's not get caught in the "support old crappy ways in new API since
> someone might have written some software depending on that"-thing that
> some operating systems are guilty of. We are not breaking anything
> here that wouldn't be broken anyway with the current method. And
> people *do* use custom widgets with libglade, at least I do. It just
> needs a little push from the application side to work, which is true
> with the gtk-tooltips issue too (just name the widget after
> construction in the application and it'll work).
>
Yep, there is no real break (as in existing code won't break,
since existing code doesn't use GtkBuilder); and in any case all those
bugs are not hard to fix/workaround. Still, why do I need to change
my code to make widget usable with GtkBuildable? The widget does
*not* violate any Gtk rules, it uses properties and whatnot.
It uses widget name just as docs say widget name is intended
to be used. And so on and so forth.
Or let's get back to "gtk-tooltips". No, symbolic colors
won't solve it as long as it's not mandatory for a theme to have
some predefined "tooltip" color, and it will never be the case.
If you write a widget which looks like a tooltip, you can't use
it with GtkBuilder, very simple.
Yes you can set the name after construction.
gtk_builder_build_stuff();
widget1 = gtk_builder_lookup ("foo");
gtk_widget_set_name (widget1, "gtk-tooltips");
/* oops, forgot to set up widget2 after adding it in glade,
since we set all the properties in glade, don't we? */
IMHO, it's silly.
I don't think it's a big deal because we won't get to the level
of doing everything in glade anyway. Still, it's a weird thing.
Anyway, let us stop. People are fine with this, good.
No need to tell how to work it around, it's clear how to
work it around; and no need to explain how it's wrong to
do these nasty things with styles, because it's *not* wrong
(it sucks one has to do things like that, indeed).
Yevgen
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>: > Kalle Vahlman wrote: > > 2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>: > >> Set widget name in constructor or init(), then create this widget with > >> GtkBuilder. > >> Yeah, "semi-broken". > > > > Why is that preferrable over matching by the widget class name? > > > See > http://svn.gnome.org/viewcvs/gtksourceview/trunk/gtksourceview/gtksourcestylescheme.c?view=markup > for cursor color thing, set_cursor_colors() function. Which part of it breaks due GtkBuilder? I don't see GtkSourceView setting it's name (nor the cursor colors) in the constructor, which was the primary concern you brought up. > For non-unique name, try > to get tooltips color on your widget without "gtk-tooltips" name. I think this: http://mail.gnome.org/archives/usability/2007-June/msg00027.html is by far a better solution to this problem than fiddling with the widget names. Let's not get caught in the "support old crappy ways in new API since someone might have written some software depending on that"-thing that some operating systems are guilty of. We are not breaking anything here that wouldn't be broken anyway with the current method. And people *do* use custom widgets with libglade, at least I do. It just needs a little push from the application side to work, which is true with the gtk-tooltips issue too (just name the widget after construction in the application and it'll work). -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Kalle Vahlman wrote: > 2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>: >> Kalle Vahlman wrote: >> > 2007/6/13, Yevgen Muntyan <[EMAIL PROTECTED]>: >> >> Kalle Vahlman wrote: >> >> > 2007/6/13, Matthias Clasen <[EMAIL PROTECTED]>: >> >> >> GtkBuilder is just setting the name that was specified in the >> xml, so >> >> >> it is not violating the principle that the widget name belongs >> to the >> >> >> app/user, since >> >> >> the xml is part of the app. >> >> >> >> >> >> >> And widget isn't part of the app? Such separation is meaningless for >> >> purpose of answering the question "should we change code of given >> >> widget if we want the widget to be usable with GtkBuider?" >> >> >> >> So, if a widget sets its name to modify its style, then >> >> it's broken? Even if the style is essential part of its >> functionality? >> >> E.g. text cursor color is not something fancy, it's an essential part >> >> of text widget and it rather sucks if cursor is invisible because of >> >> wrong styles. Saying "it's broken because it is somehow >> >> not a part of application" just doesn't make sense. >> > >> > So let's see, the things that make up a "style" in gtkrc are colors >> > and style properties. Any special-casing above (or rather below) that >> > is up to the theme engine and thus can't really be trusted. Colors are >> > grouped by functionality into fg, bg, base and text (as well as the >> > various computed colors from those). Those have clear meanings, and >> > should provide enough distinct colors for most widgets. If not, you >> > must rely on custom style properties and accept that it might not >> > match the theme. There is no way around this (other than calculating >> > the color, but that might be less than pleasing visually). >> > >> > If a widget goes bonkers because a style property had the default >> > value, maybe the default value should be made more sensible? >> >> Until gtk-2.12 there was no API to set cursor color. Try a textview >> with black background and black cursor and you'll see what I'm >> talking about ;) > > But I don't understand why this has anything to do with widget names? > If you set black on black, it'll be black on black even if you widget > is named "GreyOnWhite". > >> Try to get tooltips yellow color from a theme, without using >> "gtk-tooltips" name. > > But GtkBuilder doesn't touch that name? So why would it break? > >> And of course those custom style properties won't match theme, >> why would one change them otherwise? Thing is, sometimes you >> do need to change those style properties, and it is *not* something >> wrong or evil. > > Let me see if I can list the cases where this is neccessary: > - You implemented your custom widget and it needs style >-> match by *.class > - You implemented a custom container and wish to give style to the > children >-> match by *.class.child_class > - You implemented a custom widget with internal children and they need > style >-> name the internal child whatever and match by name > - You need to set style to it here but not there >-> name the widget you get from GtkBuilder and match by name > > Is there other cases, and why do they break down if GtkBuilder sets > the name? > >> > You said that matching the widgets in gtkrc would be a problem and in >> > the part that you didn't include here I told you it's not: >> > >> > "A quick test shows that I can indeed match my widget by the fancy >> name >> > I gave it in the code in a gtkrc, while the lookup returns the correct >> > object with the xml id." >> > >> > Did I miss something obvious here? Or did you? >> > >> >> Set widget name in constructor or init(), then create this widget with >> GtkBuilder. >> Yeah, "semi-broken". > > Why is that preferrable over matching by the widget class name? > See http://svn.gnome.org/viewcvs/gtksourceview/trunk/gtksourceview/gtksourcestylescheme.c?view=markup for cursor color thing, set_cursor_colors() function. For non-unique name, try to get tooltips color on your widget without "gtk-tooltips" name. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
2007/6/14, Yevgen Muntyan <[EMAIL PROTECTED]>: > Kalle Vahlman wrote: > > 2007/6/13, Yevgen Muntyan <[EMAIL PROTECTED]>: > >> Kalle Vahlman wrote: > >> > 2007/6/13, Matthias Clasen <[EMAIL PROTECTED]>: > >> >> GtkBuilder is just setting the name that was specified in the xml, so > >> >> it is not violating the principle that the widget name belongs to the > >> >> app/user, since > >> >> the xml is part of the app. > >> >> > >> > >> And widget isn't part of the app? Such separation is meaningless for > >> purpose of answering the question "should we change code of given > >> widget if we want the widget to be usable with GtkBuider?" > >> > >> So, if a widget sets its name to modify its style, then > >> it's broken? Even if the style is essential part of its functionality? > >> E.g. text cursor color is not something fancy, it's an essential part > >> of text widget and it rather sucks if cursor is invisible because of > >> wrong styles. Saying "it's broken because it is somehow > >> not a part of application" just doesn't make sense. > > > > So let's see, the things that make up a "style" in gtkrc are colors > > and style properties. Any special-casing above (or rather below) that > > is up to the theme engine and thus can't really be trusted. Colors are > > grouped by functionality into fg, bg, base and text (as well as the > > various computed colors from those). Those have clear meanings, and > > should provide enough distinct colors for most widgets. If not, you > > must rely on custom style properties and accept that it might not > > match the theme. There is no way around this (other than calculating > > the color, but that might be less than pleasing visually). > > > > If a widget goes bonkers because a style property had the default > > value, maybe the default value should be made more sensible? > > Until gtk-2.12 there was no API to set cursor color. Try a textview > with black background and black cursor and you'll see what I'm > talking about ;) But I don't understand why this has anything to do with widget names? If you set black on black, it'll be black on black even if you widget is named "GreyOnWhite". > Try to get tooltips yellow color from a theme, without using > "gtk-tooltips" name. But GtkBuilder doesn't touch that name? So why would it break? > And of course those custom style properties won't match theme, > why would one change them otherwise? Thing is, sometimes you > do need to change those style properties, and it is *not* something > wrong or evil. Let me see if I can list the cases where this is neccessary: - You implemented your custom widget and it needs style -> match by *.class - You implemented a custom container and wish to give style to the children -> match by *.class.child_class - You implemented a custom widget with internal children and they need style -> name the internal child whatever and match by name - You need to set style to it here but not there -> name the widget you get from GtkBuilder and match by name Is there other cases, and why do they break down if GtkBuilder sets the name? > > You said that matching the widgets in gtkrc would be a problem and in > > the part that you didn't include here I told you it's not: > > > > "A quick test shows that I can indeed match my widget by the fancy name > > I gave it in the code in a gtkrc, while the lookup returns the correct > > object with the xml id." > > > > Did I miss something obvious here? Or did you? > > > > Set widget name in constructor or init(), then create this widget with > GtkBuilder. > Yeah, "semi-broken". Why is that preferrable over matching by the widget class name? -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
Kalle Vahlman wrote: > 2007/6/13, Yevgen Muntyan <[EMAIL PROTECTED]>: >> Kalle Vahlman wrote: >> > 2007/6/13, Matthias Clasen <[EMAIL PROTECTED]>: >> >> GtkBuilder is just setting the name that was specified in the xml, so >> >> it is not violating the principle that the widget name belongs to the >> >> app/user, since >> >> the xml is part of the app. >> >> >> >> And widget isn't part of the app? Such separation is meaningless for >> purpose of answering the question "should we change code of given >> widget if we want the widget to be usable with GtkBuider?" >> >> So, if a widget sets its name to modify its style, then >> it's broken? Even if the style is essential part of its functionality? >> E.g. text cursor color is not something fancy, it's an essential part >> of text widget and it rather sucks if cursor is invisible because of >> wrong styles. Saying "it's broken because it is somehow >> not a part of application" just doesn't make sense. > > So let's see, the things that make up a "style" in gtkrc are colors > and style properties. Any special-casing above (or rather below) that > is up to the theme engine and thus can't really be trusted. Colors are > grouped by functionality into fg, bg, base and text (as well as the > various computed colors from those). Those have clear meanings, and > should provide enough distinct colors for most widgets. If not, you > must rely on custom style properties and accept that it might not > match the theme. There is no way around this (other than calculating > the color, but that might be less than pleasing visually). > > If a widget goes bonkers because a style property had the default > value, maybe the default value should be made more sensible? Until gtk-2.12 there was no API to set cursor color. Try a textview with black background and black cursor and you'll see what I'm talking about ;) Try to get tooltips yellow color from a theme, without using "gtk-tooltips" name. And of course those custom style properties won't match theme, why would one change them otherwise? Thing is, sometimes you do need to change those style properties, and it is *not* something wrong or evil. > >> > Furthermore, if my (admittedly quick) glance over how the object names >> > are handled is not misguided, GtkBuilder sets the name once and never >> > checks it again. It has an internal hash table in which it stores the >> > id in the xml and all lookups use that instead of referring to the >> > actual name. >> > >> > So even if GtkBuilder sets the initial name to what is in the xml, you >> > should be able to change it afterwards to whatever you like without >> > everything going bork bork. >> > >> >> I said already what could be a problem. get_widget_by_name() >> is irrelevant. > > You said that matching the widgets in gtkrc would be a problem and in > the part that you didn't include here I told you it's not: > > "A quick test shows that I can indeed match my widget by the fancy name > I gave it in the code in a gtkrc, while the lookup returns the correct > object with the xml id." > > Did I miss something obvious here? Or did you? > Set widget name in constructor or init(), then create this widget with GtkBuilder. Yeah, "semi-broken". Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkBuilder Public API - Last call
2007/6/13, Yevgen Muntyan <[EMAIL PROTECTED]>: > Kalle Vahlman wrote: > > 2007/6/13, Matthias Clasen <[EMAIL PROTECTED]>: > >> GtkBuilder is just setting the name that was specified in the xml, so > >> it is not violating the principle that the widget name belongs to the > >> app/user, since > >> the xml is part of the app. > >> > > And widget isn't part of the app? Such separation is meaningless for > purpose of answering the question "should we change code of given > widget if we want the widget to be usable with GtkBuider?" > > So, if a widget sets its name to modify its style, then > it's broken? Even if the style is essential part of its functionality? > E.g. text cursor color is not something fancy, it's an essential part > of text widget and it rather sucks if cursor is invisible because of > wrong styles. Saying "it's broken because it is somehow > not a part of application" just doesn't make sense. So let's see, the things that make up a "style" in gtkrc are colors and style properties. Any special-casing above (or rather below) that is up to the theme engine and thus can't really be trusted. Colors are grouped by functionality into fg, bg, base and text (as well as the various computed colors from those). Those have clear meanings, and should provide enough distinct colors for most widgets. If not, you must rely on custom style properties and accept that it might not match the theme. There is no way around this (other than calculating the color, but that might be less than pleasing visually). If a widget goes bonkers because a style property had the default value, maybe the default value should be made more sensible? > > Furthermore, if my (admittedly quick) glance over how the object names > > are handled is not misguided, GtkBuilder sets the name once and never > > checks it again. It has an internal hash table in which it stores the > > id in the xml and all lookups use that instead of referring to the > > actual name. > > > > So even if GtkBuilder sets the initial name to what is in the xml, you > > should be able to change it afterwards to whatever you like without > > everything going bork bork. > > > > I said already what could be a problem. get_widget_by_name() > is irrelevant. You said that matching the widgets in gtkrc would be a problem and in the part that you didn't include here I told you it's not: "A quick test shows that I can indeed match my widget by the fancy name I gave it in the code in a gtkrc, while the lookup returns the correct object with the xml id." Did I miss something obvious here? Or did you? -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
