John Spray wrote:
> Note that my GView.C is different to yours, with a single (yet critical)
> false instead of a true. Patch attached for you to try out if you like.
I have tried it out and it makes all the difference. Thank you. I'll commit
this for you because I like it so much ;-)
--
Angus
On Sat, 2004-10-02 at 18:48, Jean-Marc Lasgouttes wrote:
> I do not know... I just assumed it was possible ;) But if you say it
> is not, I believe you...
If there are no further suggestions, I'll commit this.
John
> "John" == John Spray <[EMAIL PROTECTED]> writes:
John> How do you propose to read the accelerator text out of the
John> accellabel? Note that the get_text() function returns just the
John> text that we set: ie "_New" rather than "_New Ctrl+N".
I do not know... I just assumed it was possible
On Sat, 2004-10-02 at 10:01, Jean-Marc Lasgouttes wrote:
> No, what I had in mind was in GLyXKeySym::print, to create a dummy
> widget, attach a accellabel to it, set the acellerator and then read
> the label string from there.
>
> I understand this looks a bit weird, but won't this work?
How do y
> "John" == John Spray <[EMAIL PROTECTED]> writes:
John> On Fri, 2004-10-01 at 15:17, Jean-Marc Lasgouttes wrote:
>> Can't GtkAccelLabel be used for that?
John> AccelLabel displays an accelerator next to the label, but the
John> accelerator is set by associating the accellabel with a widget
J
On Fri, 2004-10-01 at 15:17, Jean-Marc Lasgouttes wrote:
> Can't GtkAccelLabel be used for that?
AccelLabel displays an accelerator next to the label, but the
accelerator is set by associating the accellabel with a widget which
uses that accelerator. That means that we're not just displaying the
> "John" == John Spray <[EMAIL PROTECTED]> writes:
John> Sorry, I wasn't quite clear: I mean that the function exists
John> within GTK+, but isn't in the GTK+ interface. GTK+ just has a
John> gtk_accelerator_name function whose output is equivalent to the
John> get_abbrev in gtkmm. There doesn
On Thu, 2004-09-30 at 15:29, Jean-Marc Lasgouttes wrote:
> John> Gtk::AccelKey::get_abbrev unfortunately only outputs the
> John> gtk-parsable form "n". Good idea though, it's somewhat
> John> annoying that gtk won't give us its human-readable version (of
> John> course, such a function exists insi
> "John" == John Spray <[EMAIL PROTECTED]> writes:
John> On Wed, 2004-09-29 at 15:39, Jean-Marc Lasgouttes wrote:
>> Hmm, couldn't you use this constructor in GLyXKeySym::print and
>> transform this into a string? This would look better than adding
>> 'Ctrl+' by hand, IMO.
John> Gtk::AccelKey:
Angus Leeming wrote:
> John Spray wrote:
>> I don't get it. See what it looks like for me:
>> http://icculus.org/~jcspray/lyx-gtk.png
>
> I get a whopping great minibuffer that takes up half the screen.
>
>> Note that my GView.C is different to yours, with a single (yet
>> critical) false inste
John Spray wrote:
> I don't get it. See what it looks like for me:
> http://icculus.org/~jcspray/lyx-gtk.png
I get a whopping great minibuffer that takes up half the screen.
> Note that my GView.C is different to yours, with a single (yet
> critical) false instead of a true.
> Patch attached for
Oops, clicked Send too soon on previous reply.
On Wed, 2004-09-29 at 15:31, Angus Leeming wrote:
> Incidentally, whilst all these dialogs are nice, you should see how
> the Gtk frontend looks with multiple toolbars activated. Try changing
> lib/ui/default.ui to
I should probably explain my reaso
On Wed, 2004-09-29 at 15:31, Angus Leeming wrote:
> You don't check "!symname.empty()", so this is unsafe.
Thanks.
Revised patch attached.
> Also, why not:
>
> string buf;
> if (mod & key_modifier::shift)
> buf = "Shift+";
> if (mod & key_modifier::ctrl)
On Wed, 2004-09-29 at 15:39, Jean-Marc Lasgouttes wrote:
> Hmm, couldn't you use this constructor in GLyXKeySym::print and
> transform this into a string? This would look better than adding
> 'Ctrl+' by hand, IMO.
Gtk::AccelKey::get_abbrev unfortunately only outputs the gtk-parsable
form "n". Good
> "John" == John Spray <[EMAIL PROTECTED]> writes:
John> Attached patch should sort this issue: Add gtk+ style
John> accelerator labels to menu items. Previous runtime warnings have
John> of course vanished because we're not using Gtk accels any more,
John> just plain old labels.
It looks OK
John Spray wrote:
> +*symname.begin() =
> lyx::support::uppercase(*symname.begin());
> +buf += symname;
You don't check "!symname.empty()", so this is unsafe. Also, why not:
string buf;
if (mod & key_modifier::shift)
buf = "Shift+";
i
Right, here's how I've handled this issue:
-modify GLyXKeySym.C to produce nicer human-readable accelerators like
Ctrl+N. Not functionally necessary, but better UI.
-In GMenubar.C, load two labels (item name and accel string) into an
hbox and load the hbox into a menuitem. It's not that concise,
> "John" == John Spray <[EMAIL PROTECTED]> writes:
John> On Wed, 2004-09-29 at 08:44, Jean-Marc Lasgouttes wrote:
>> And what would be the right gtkmm method to get a nice
>> human-readable version?
John> Well, I'm currently using a modified GLyXKeySym::print to
John> produce gtk-style strings
On Wed, 2004-09-29 at 08:44, Jean-Marc Lasgouttes wrote:
> And what would be the right gtkmm method to get a nice human-readable
> version?
Well, I'm currently using a modified GLyXKeySym::print to produce
gtk-style strings like "Ctrl+N" (in fact, this is also the normal style
for qt apps, so I don
> "John" == John Spray <[EMAIL PROTECTED]> writes:
John> On Tue, 2004-09-28 at 16:24, John Spray wrote:
>> > While I do not have anything useful to say about the errors, I'd
>> like > to point you to GLyXKeySym::print, which is the right hook
>> for > generating a correct string corresponding
On Tue, 2004-09-28 at 16:24, John Spray wrote:
> > While I do not have anything useful to say about the errors, I'd like
> > to point you to GLyXKeySym::print, which is the right hook for
> > generating a correct string corresponding to a given keysym. Currently
> > it points to kb_keymap::printKey
On Tue, 2004-09-28 at 15:08, Jean-Marc Lasgouttes wrote:
> While I do not have anything useful to say about the errors, I'd like
> to point you to GLyXKeySym::print, which is the right hook for
> generating a correct string corresponding to a given keysym. Currently
> it points to kb_keymap::printK
> "John" == John Spray <[EMAIL PROTECTED]> writes:
John> Hi, I've written a function (attached patch) to take something
John> like "S-C-n" and translate it into the "n" form
John> that GTK wants for its accelerators. However, when I add
John> accelerators to menu elements (not just the ones my
Hi,
I've written a function (attached patch) to take something like "S-C-n"
and translate it into the "n" form that GTK wants for
its accelerators. However, when I add accelerators to menu elements
(not just the ones my function generates, any accelerator will do)
runtime errors are generated at
24 matches
Mail list logo
