I cannot verify it as I do not have any Ubuntu machine any more so,
close freely if it seems fixed.
--
gtkdoc-fixxref broken by compressed documentation
https://bugs.launchpad.net/bugs/77138
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
> looks like you made preferences loading dependent on gui mode
I wonder what makes it look so to you.
The code clearly says otherwise.
Or did you try it and found that preferences are not loaded? I did and
the preferences are loaded. Changing the plain SVG indentation amount
to a non-default
No, the patch does no such thing. Please look at what function
sp_input_load_from_preferences() really does.
Preferences are loaded the first something needs them, i.e. the first
time Inkscape::Preferences::get() is called. So, if something needs
them they will be loaded in due time.
Beside obt
Still observing this with inkscape-0.47pre1. The fix is attached --
tested on X11, no idea what implications inkscape->use_gui has on non-
unix systems but the assertion that we should not run GDK functions when
it's false seems generally correct.
** Attachment added: "inkscape-0.47pre1-without-
What the...
Please forget bug report has been ever submitted. Thank you for your
time.
--
gtkdoc-fixxref broken by compressed documentation
https://bugs.launchpad.net/bugs/77138
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
> This is because you don't wont to read the actual arguments people are making:
> saving space is still an issue for example in live CDs, embedded systems
> (where one still has to ship some files such as copyrights), or simply to
> email them;
> zipping still provides a speed advantage when the
>> The complexity of every simple private or one-shot script that reads these
>> files
>> is considerably increased.
> This is why we use wrappers, libraries, or whatever to handle input formats,
> instead of writing a parser for each program.
Many of these files are not in `formats'. They are
> After all, these are not that hard to support from Perl
This way of thinking is the source of all the problems. Sure, it is not
hard to add compression support in a one particular case. But then then
is another case, then a couple of them, yet another, a few more, and it
never stops. The comp
Public bug reported:
Ubuntu: 6.10
gnuplot-doc: 4.0.0-3
Several data files (*.dat) in /usr/share/doc/gnuplot-doc/examples, and
even some gnuplot scripts (*.dem) are compressed. This breaks the demos
since gnuplot can neither read compressed files nor it looks for file
names ending with .gz.
Steps
Public bug reported:
Binary package hint: gtk-doc-tools
One of the primary function of gtkdoc-fixxref is to point references to
standard GLib, Gtk+, etc. symbols (types, functions, macros, etc.) in
generated documentation to the system documentation if present. In
other words, if another library
10 matches
Mail list logo
