guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#28421] [PATCH] gnu: Add uim.


From: Ludovic Courtès
Subject: [bug#28421] [PATCH] gnu: Add uim.
Date: Thu, 14 Sep 2017 09:00:15 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Hi Arun,

Arun Isaac <address@hidden> skribis:

>>> * gnu/packages/xorg.scm (uim): New variable.
>>
>> [...]
>>
>>> +    (native-inputs
>>> +     `(("anthy" ,anthy)
>>> +       ("emacs" ,emacs-minimal)
>>> +       ("gtk+" ,gtk+)
>>> +       ("gtk+" ,gtk+-2)
>>> +       ("intltool" ,intltool)
>>> +       ("pkg-config" ,pkg-config)
>>> +       ("qt" ,qt-4)))
>>
>> GTK+ and Qt are native inputs?
>
> The package has gtk and qt programs to set uim preferences. At least,
> those must need gtk and qt as inputs. So, you're right -- gtk and qt
> should be inputs, not native inputs.
>
> Also, I think anthy should be an input, not a native input.

OK.

>> Also, is Qt 5 supported?  That would be best.
>
> It looks there is no release yet that supports Qt 5, though there is
> support in the master branch.
>
> https://github.com/uim/uim/issues/61

Good.

>> Besides, would it make sense to split the thing into several outputs to
>> avoid the huge dependencies?
>
> I don't know if it's a good idea to split the package into a gtk output
> and a qt output. What if the user needs multilingual input in both gtk
> and qt programs?
>
> Also, this package can be built in many different ways -- with and
> without the gtk and qt helper programs (for uim preferences), with and
> without anthy support, with and without m17nlib support, etc. I don't
> know where to draw the line, and choose only a few outputs. The
> configure flags and dependencies, as they stand now, I copied from Arch
> Linux.
>
> https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/uim

I think the question is: are GTK+ and Qt needed just for the preference
UI, or are they needed to enable support for this input method in GTK+
and Qt applications?

If it’s the latter, we definitely need to keep both.

If it’s the former, perhaps we can have one package that simply provides
libuim and does not depend on a GUI toolkit (“uim-minimal”), and another
one (or two) that provide the GUIs.  Alternately, there could be a “lib”
output (no dependency on GTK+/Qt).

Thoughts?

Thanks,
Ludo’.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]