On 25 Feb, Sven Neumann wrote:
> Don't waste your time at that. I already did that and I tried to
> explain you why there is no way to hook into that place since GTK+
> creates the submenu on the fly. At the time we create the tearoff
> menu, the submenu is already created. But when the submenu i
Hi,
> Look at the code we already have to add the tearoff menus. A similar
> thing could be used to create the branches itself.
Don't waste your time at that. I already did that and I tried to explain
you why there is no way to hook into that place since GTK+ creates the
submenu on the fly.
On 25 Feb, Sven Neumann wrote:
> Which is exactly what I proposed at the end of my last mail. Despite
> that I proposed to build up the menu-structure (actually only the
> strings) in a hash-table before actually creating it.
For a new translation function I guess?
> Would be much
> faster the
Hi,
> Yes. That's why I thought of ripping off a slice from both the
> translation AND the original.
>
> Consider this:
> Plugin wants to create a menu /Filters/verynew/stupidtool.
> Now we first check:
> - Is there a menu /Filters/verynew
>-> if not continue ripping off until we found
On 24 Feb, Sven Neumann wrote:
> On the first thought the idea looks promising, but I fear it is
> not that easy. GTK+ wants to create the menu using the orginal
> strings.
Yes. That's why I thought of ripping off a slice from both the
translation AND the original.
Consider this:
Plugin wa
Hi,
>
> I'd suggest testing for existance of the parent menu first and
> if it's not there extracting the correct translation for it from
> the full path and initialize it together with the tearoff menu.
On the first thought the idea looks promising, but I fear it is
not that easy. GTK+ wants
On 24 Feb, Sven Neumann wrote:
> Eek, yes of course, that does not work any more. There are
> two ways to solve this: Either we search in the gimp domain
> if the lookup of the menupath failed (like we used to do (*))
> or we move the dummies into the plugins. I prefer the latter,
> since it is
On 24 Feb, Sven Neumann wrote:
> the new i18n implementation supports localisation of
> plugins outside the gimp distribution. I'm pretty sure
> that it works. I have however not yet tested if it
> really does what we expect and if it solves the problems
> it targets. Is there anyone out there
Hi,
SHIRASAKI Yasuhiro <[EMAIL PROTECTED]> noticed:
> some paths like:
>
> /Video
> /Script-Fu/*
>
> are not translated with "The i18n solution"(TM).
> Shell we move dummy_entries[] items from app/menus.c
> to each appropriate plug-ins?
Eek, yes of course, that does not work any more. There
Hi,
the new i18n implementation supports localisation of
plugins outside the gimp distribution. I'm pretty sure
that it works. I have however not yet tested if it
really does what we expect and if it solves the problems
it targets. Is there anyone out there maintaining a
seperate plugin who is
10 matches
Mail list logo
