Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #136309 > unrolled thread

Trying to install GEDIT

Back to article view | Back to comp.lang.c

Contents

  Trying to install GEDIT jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-05 22:00 +0200
    Re: Trying to install GEDIT Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2018-10-05 20:10 +0000
      Re: Trying to install GEDIT jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-07 18:02 +0200
        Re: Trying to install GEDIT Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-10-07 12:31 -0400
        Re: Trying to install GEDIT Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-07 17:13 +0000
        Re: Trying to install GEDIT Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-07 12:11 -0700
        Re: Trying to install GEDIT Jasen Betts <jasen@xnet.co.nz> - 2018-10-08 02:40 +0000
    Re: Trying to install GEDIT scott@slp53.sl.home (Scott Lurndal) - 2018-10-05 20:15 +0000
      Re: Trying to install GEDIT David Kleinecke <dkleinecke@gmail.com> - 2018-10-05 18:16 -0700
      Re: Trying to install GEDIT Jasen Betts <jasen@xnet.co.nz> - 2018-10-06 02:34 +0000
    Re: Trying to install GEDIT Spiros Bousbouras <spibou@gmail.com> - 2018-10-06 03:57 +0000
      Re: Trying to install GEDIT jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-06 09:45 +0200
        Re: Trying to install GEDIT Ian Collins <ian-news@hotmail.com> - 2018-10-06 22:13 +1300
        Re: Trying to install GEDIT David Brown <david.brown@hesbynett.no> - 2018-10-06 16:14 +0200
        Re: Trying to install GEDIT scott@slp53.sl.home (Scott Lurndal) - 2018-10-06 14:53 +0000
          Re: Trying to install GEDIT jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-06 19:42 +0200
    Re: Trying to install GEDIT C W Rose <cwr@seckford.org> - 2018-10-06 20:57 +0100
    Re: Trying to install GEDIT Melzzzzz <Melzzzzz@zzzzz.com> - 2018-10-07 13:48 +0000

#136309 — Trying to install GEDIT

Hi folks

I tried to install the open source package "GEDIT".

It needed a Tex package, and a Tex installation, what I did download. 
But then it needs "style sheets" (whatever that may be)

It crashed during ./autogen.sh with missing xslt-stylesheets.

So, I cloned
git clone https://github.com/docbook/xslt10-stylesheets.git

OK

Bu then it says it needs perl package xml-xpath. I figured out that issuing
sudo apt-get install libxml-xpath-perl

would fix that.

Then it needed to read a file called .xmlc. After an houro so searching 
I came to see an invisible fdirectory in the download of xstyle-sheets 
called ".trevis" and ythere I found a xmlc file. I copied that to my 
home directory and the script went a little bit further.

A package called "xerces" was needed. I found that and wen further.
I installed then a package that is called "saxon", that asked for money.
Happily there is a free version, but apparently it will not work.

   1 Exception in thread "main" java.lang.NoClassDefFoundError: 
com.icl.saxon.StyleSheet
   2    at gnu.java.lang.MainThread.run(libgcj.so.17)
   3 Caused by: java.lang.ClassNotFoundException: 
com.icl.saxon.StyleSheet not found in gnu.gcj.runtime.System 
ClassLoader{urls=[file:/usr/share/java/saxon.jar,file:/usr/share/java/xercesImpl.jar,file:/usr/share/java 
    /xml-resolver.jar], 
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
   4    at java.net.URLClassLoader.findClass(libgcj.so.17)
   5    at java.lang.ClassLoader.loadClass(libgcj.so.17)
   6    at java.lang.ClassLoader.loadClass(libgcj.so.17)
   7    at gnu.java.lang.MainThread.run(libgcj.so.17)
   8 make[2]: *** [af.xml] Error 1
   9 Exception in thread "main" java.lang.NoClassDefFoundError: 
com.icl.saxon.StyleSheet
  10    at gnu.java.lang.MainThread.run(libgcj.so.17)
  11 Caused by: java.lang.ClassNotFoundException: 
com.icl.saxon.StyleSheet not found in gnu.gcj.runtime.System 
ClassLoader{urls=[file:/usr/share/java/saxon.jar,file:/usr/share/java/xercesImpl.jar,file:/usr/share/java 
    /xml-resolver.jar], 
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}

I wanted to study Gedit because I want to write an editor and I thought 
that I could learn it by studying the "gedit" source code, that is 
advertised as an editor written in C.

Why a C program will need java/perl/xml/ etc is beyond me.

Why the documentation is mandatory? Why do I need all those megabytes of 
different languages to compile a C-GTK based editor?

Mystery.

If anyone can tell me how to proceed I would be thankful.

Thanks in advance

Jacob

[toc] | [next] | [standalone]

#136311

On Fri, 05 Oct 2018 22:00:15 +0200, jacobnavia wrote:

> Why do I need all those megabytes of different languages to compile a C-
> GTK based editor?
> 
> Mystery.

	Not at all - it's a text editor for the GNOME environment. 
Throwing all sorts of stuff into the mix is par for the course for this 
desktop environment, which is succeeding beyond all expectation at making 
sure that Linux remains a nonentity in the desktop.

[toc] | [prev] | [next] | [standalone]

#136389

Le 05/10/2018 à 22:10, Jens Stuckelberger a écrit :
> On Fri, 05 Oct 2018 22:00:15 +0200, jacobnavia wrote:
> 
>> Why do I need all those megabytes of different languages to compile a C-
>> GTK based editor?
>>
>> Mystery.
> 
> 	Not at all - it's a text editor for the GNOME environment.
> Throwing all sorts of stuff into the mix is par for the course for this
> desktop environment, which is succeeding beyond all expectation at making
> sure that Linux remains a nonentity in the desktop.
> 

Excuse me my ignorance but I thought that GTK+ was the equivalent of the 
windows API for linux.

Is that wrong?

What other window APIs are there to use?

Thanks

[toc] | [prev] | [next] | [standalone]

#136391

jacobnavia wrote:

> Le 05/10/2018 à 22:10, Jens Stuckelberger a écrit :
>> On Fri, 05 Oct 2018 22:00:15 +0200, jacobnavia wrote:
>> 
>>> Why do I need all those megabytes of different languages to compile a C-
>>> GTK based editor?
>>>
>>> Mystery.
>> 
>> Not at all - it's a text editor for the GNOME environment.
>> Throwing all sorts of stuff into the mix is par for the course for this
>> desktop environment, which is succeeding beyond all expectation at making
>> sure that Linux remains a nonentity in the desktop.
>> 
> 
> Excuse me my ignorance but I thought that GTK+ was the equivalent of the
> windows API for linux.
> 
> Is that wrong?
> 
> What other window APIs are there to use?

Long story short, Linux doesn't have /a/ windowing API; it has /many/ 
windowing APIs. Pick one. You can start here
https://en.wikipedia.org/wiki/List_of_platform-independent_GUI_libraries



-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#136396

On 2018-10-07, jacobnavia <jacob@jacob.remcomp.fr> wrote:
> Le 05/10/2018 à 22:10, Jens Stuckelberger a écrit :
>> On Fri, 05 Oct 2018 22:00:15 +0200, jacobnavia wrote:
>> 
>>> Why do I need all those megabytes of different languages to compile a C-
>>> GTK based editor?
>>>
>>> Mystery.
>> 
>> 	Not at all - it's a text editor for the GNOME environment.
>> Throwing all sorts of stuff into the mix is par for the course for this
>> desktop environment, which is succeeding beyond all expectation at making
>> sure that Linux remains a nonentity in the desktop.
>> 
>
> Excuse me my ignorance but I thought that GTK+ was the equivalent of the 
> windows API for linux.
>
> Is that wrong?
>
> What other window APIs are there to use?

Qt. Plain X, plain Wayland and others...

>
> Thanks


-- 
press any key to continue or any other to quit...

[toc] | [prev] | [next] | [standalone]

#136397

On Sunday, October 7, 2018 at 5:02:55 PM UTC+1, jacobnavia wrote:
> Le 05/10/2018 à 22:10, Jens Stuckelberger a écrit :
> > On Fri, 05 Oct 2018 22:00:15 +0200, jacobnavia wrote:
> > 
> >> Why do I need all those megabytes of different languages to compile a C-
> >> GTK based editor?
> >>
> >> Mystery.
> > 
> > 	Not at all - it's a text editor for the GNOME environment.
> > Throwing all sorts of stuff into the mix is par for the course for this
> > desktop environment, which is succeeding beyond all expectation at making
> > sure that Linux remains a nonentity in the desktop.
> > 
> 
> Excuse me my ignorance but I thought that GTK+ was the equivalent of the 
> windows API for linux.
> 
> Is that wrong?
> 
> What other window APIs are there to use?
> 
There's Baby X.

https://github.com/MalcolmMcLean/babyx

[toc] | [prev] | [next] | [standalone]

#136416

On 2018-10-07, jacobnavia <jacob@jacob.remcomp.fr> wrote:
> Le 05/10/2018 à 22:10, Jens Stuckelberger a écrit :
>> On Fri, 05 Oct 2018 22:00:15 +0200, jacobnavia wrote:
>> 
>>> Why do I need all those megabytes of different languages to compile a C-
>>> GTK based editor?
>>>
>>> Mystery.
>> 
>> 	Not at all - it's a text editor for the GNOME environment.
>> Throwing all sorts of stuff into the mix is par for the course for this
>> desktop environment, which is succeeding beyond all expectation at making
>> sure that Linux remains a nonentity in the desktop.
>> 
>
> Excuse me my ignorance but I thought that GTK+ was the equivalent of the 
> windows API for linux.
> Is that wrong?


GTK+ is an application framework.  the windowing API is Xlib

other frameowrks include 

Lesstiff, Xforms (X11 not W3C), SDL, Qt, Tk, Xaw

some of those are also available on MS-windows,


-- 
  Notsodium is mined on the banks of denial.

[toc] | [prev] | [next] | [standalone]

#136312

jacobnavia <jacob@jacob.remcomp.fr> writes:
>Hi folks
>
>I tried to install the open source package "GEDIT".

Using what linux distribution?   All of them should have
the binary package available, and most of them have the
corresponding source code package available for download
which contains any configuration differences from the
upstream package required to build for your distribution.

E.g. Redhat has .srpms for each .rpm package.  Install
the source package and use rpmbuild to initiate a rebuild
of the package.   I'm sure the other distros have a method
to build from source any package they ship as a binary package.

>
>I wanted to study Gedit because I want to write an editor and I thought 
>that I could learn it by studying the "gedit" source code, that is 
>advertised as an editor written in C.

Try vim instead.  Although it also has many dependencies, many of which
can be configured out with options to the ./configure command you
use to build it.  It will use GTK2 if present to provide a GUI version.

https://www.vim.org/

gedit is heavily tied to the gnome desktop.

>
>Why a C program will need java/perl/xml/ etc is beyond me.

Modern editors generally do far more than just allow one to edit text.

The description of gedit itself (see its wiki page) should help
you to understand why a C program needs xml support (and perl to support
PCRE):

  "gedit is the default text editor of the GNOME desktop
   environment and part of the GNOME Core Applications. ...
   It includes tools for editing source code and structured
   text such as markup languages."


>
>Why the documentation is mandatory? Why do I need all those megabytes of 
>different languages to compile a C-GTK based editor?
>
>Mystery.
>
>If anyone can tell me how to proceed I would be thankful.
>

See above.  Use the source package distributed by your distribution.

If you're trying to build on windows, use the Ubuntu WSL, don't
bother with mingw or cygwin.

[toc] | [prev] | [next] | [standalone]

#136317

On Friday, October 5, 2018 at 1:15:17 PM UTC-7, Scott Lurndal wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
> >Hi folks
> >
> >I tried to install the open source package "GEDIT".
> 
> Using what linux distribution?   All of them should have
> the binary package available, and most of them have the
> corresponding source code package available for download
> which contains any configuration differences from the
> upstream package required to build for your distribution.
> 
> E.g. Redhat has .srpms for each .rpm package.  Install
> the source package and use rpmbuild to initiate a rebuild
> of the package.   I'm sure the other distros have a method
> to build from source any package they ship as a binary package.
> 
> >
> >I wanted to study Gedit because I want to write an editor and I thought 
> >that I could learn it by studying the "gedit" source code, that is 
> >advertised as an editor written in C.
> 
> Try vim instead.  Although it also has many dependencies, many of which
> can be configured out with options to the ./configure command you
> use to build it.  It will use GTK2 if present to provide a GUI version.
> 
> https://www.vim.org/
> 
> gedit is heavily tied to the gnome desktop.
> 
> >
> >Why a C program will need java/perl/xml/ etc is beyond me.
> 
> Modern editors generally do far more than just allow one to edit text.
> 
> The description of gedit itself (see its wiki page) should help
> you to understand why a C program needs xml support (and perl to support
> PCRE):
> 
>   "gedit is the default text editor of the GNOME desktop
>    environment and part of the GNOME Core Applications. ...
>    It includes tools for editing source code and structured
>    text such as markup languages."
> 
> 
> >
> >Why the documentation is mandatory? Why do I need all those megabytes of 
> >different languages to compile a C-GTK based editor?
> >
> >Mystery.
> >
> >If anyone can tell me how to proceed I would be thankful.
> >
> 
> See above.  Use the source package distributed by your distribution.
> 
> If you're trying to build on windows, use the Ubuntu WSL, don't
> bother with mingw or cygwin.

I don't recommend gedit as a good learning example of
an editor. The GTK+ world is too baroque. 

I downloaded the source code - which depends heavily on
the GTK+ - without difficulty a few years ago. I tried to
do the same on my new Windows 10 machine recently and
was stopped by the need for .xz decompressing (it looks
easy enough to get but I've been busy on other matters).

I did download the object and continue to use gedit as 
my editor of choice for simple stuff.

PS GTK+ and Gedit are C90 code. Or were.
 

[toc] | [prev] | [next] | [standalone]

#136322

On 2018-10-05, Scott Lurndal <scott@slp53.sl.home> wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>Hi folks
>>
>>I tried to install the open source package "GEDIT".
>

>>
>>Why a C program will need java/perl/xml/ etc is beyond me.
>
> Modern editors generally do far more than just allow one to edit text.
>
> The description of gedit itself (see its wiki page) should help
> you to understand why a C program needs xml support (and perl to support
> PCRE):

perl is not requiored for PCRE, PCRE is a separate C library - an
off-shoot of the Exim MTA project, not a descendant of perl.

>   "gedit is the default text editor of the GNOME desktop
>    environment and part of the GNOME Core Applications. ...
>    It includes tools for editing source code and structured
>    text such as markup languages."

>>Why the documentation is mandatory? Why do I need all those megabytes of 
>>different languages to compile a C-GTK based editor?

It's because the devs decided to put the docs in the same repo as as the
software.

> See above.  Use the source package distributed by your distribution.

> If you're trying to build on windows, use the Ubuntu WSL, don't
> bother with mingw or cygwin.

Yeah, mingw can be tricky. but most Gnome/GTK libraries are available if
you look hard enough.

-- 
  Notsodium is mined on the banks of denial.

[toc] | [prev] | [next] | [standalone]

#136324

On Fri, 5 Oct 2018 22:00:15 +0200
jacobnavia <jacob@jacob.remcomp.fr> wrote:
> Hi folks
> 
> I tried to install the open source package "GEDIT".
> 
> It needed a Tex package, and a Tex installation, what I did download. 
> But then it needs "style sheets" (whatever that may be)
> 
> It crashed during ./autogen.sh with missing xslt-stylesheets.

Crashed or exited with an error message ? If it crashed then perhaps you
need to submit a bug report somehwere.

[...]

> I wanted to study Gedit because I want to write an editor and I thought 
> that I could learn it by studying the "gedit" source code, that is 
> advertised as an editor written in C.

Just what the world needs , another text editor. vim , emacs , nano  and
many other text editors are written in C. Is there anything in particular
you want to learn ? Is your editor meant to run on console or a graphical
environment ?

[toc] | [prev] | [next] | [standalone]

#136325

Le 06/10/2018 à 05:57, Spiros Bousbouras a écrit :
> Just what the world needs , another text editor

I started writing the debugger for my linux version of lcc-win. It uses 
the ptrace interface.

If I have my own debugger, I could use the same debugging info format as 
I use under windows or use the "stabs" format, that I generate correctly 
now.

If I would use the gnu "gdb" I would have to generate DWARF debug info, 
what is an horrible MESS!

And I do want to show the CONTEXT where the program is executing, and 
for that I need a text editor!

Besides I want a modern debugger, with automatic variable dispmlay (no 
longer needed to write "print foo print bar" at each line like in gdb.

Besides an IDE would be handy to make it easier to use the compiler. I 
have already one under windows, so I wanted to rewrite a better one 
under linux.

[toc] | [prev] | [next] | [standalone]

#136326

On 06/10/18 20:45, jacobnavia wrote:
> Le 06/10/2018 à 05:57, Spiros Bousbouras a écrit :
>> Just what the world needs , another text editor
> 
> I started writing the debugger for my linux version of lcc-win. It uses
> the ptrace interface.
> 
> If I have my own debugger, I could use the same debugging info format as
> I use under windows or use the "stabs" format, that I generate correctly
> now.
> 
> If I would use the gnu "gdb" I would have to generate DWARF debug info,
> what is an horrible MESS!
> 
> And I do want to show the CONTEXT where the program is executing, and
> for that I need a text editor!
> 
> Besides I want a modern debugger, with automatic variable dispmlay (no
> longer needed to write "print foo print bar" at each line like in gdb.
> 
> Besides an IDE would be handy to make it easier to use the compiler. I
> have already one under windows, so I wanted to rewrite a better one
> under linux.

Why don't you just integrate your debugger with an existing IDE (or 
three)?  Most id not all IDEs on Linux work with gdb, so you should be 
able to use what has already be written.

-- 
Ian.

[toc] | [prev] | [next] | [standalone]

#136343

On 06/10/18 09:45, jacobnavia wrote:
> Le 06/10/2018 à 05:57, Spiros Bousbouras a écrit :
>> Just what the world needs , another text editor
> 
> I started writing the debugger for my linux version of lcc-win. It uses 
> the ptrace interface.
> 
> If I have my own debugger, I could use the same debugging info format as 
> I use under windows or use the "stabs" format, that I generate correctly 
> now.
> 
> If I would use the gnu "gdb" I would have to generate DWARF debug info, 
> what is an horrible MESS!

gdb should be fine with stabs, I think.

Dwarf is the modern format for debugging information because it can 
support far more detail than stabs - things like macro definitions, 
tracking variables as they move between registers, showing structs that 
are partly in registers, variables that have been eliminated or 
transformed by optimisation, etc.  I can well believe that it is a much 
more complex format as it supports those features.

But AFAIUI gdb supports other formats, including stabs.

> 
> And I do want to show the CONTEXT where the program is executing, and 
> for that I need a text editor!
> 
> Besides I want a modern debugger, with automatic variable dispmlay (no 
> longer needed to write "print foo print bar" at each line like in gdb.
> 
> Besides an IDE would be handy to make it easier to use the compiler. I 
> have already one under windows, so I wanted to rewrite a better one 
> under linux.
> 
> 

I fully agree that using an IDE is useful.  Perhaps you could use 
something like Eclipse or Netbeans as the IDE, and talk to the debugger 
in the same way as they talk to gdb?  If your debugger supports the same 
MI interface as gdb, then you could use the existing debugger support in 
those IDEs.  If your debugger has its own methods for communicating with 
the gui, then you might need to make your own plugins - that would, I 
think, mean Java programming, but it would be a smaller project than 
writing everything from scratch.

If you can use gdb, it would be easier - then you can use an existing 
debugger and a range of existing IDEs on many platforms.

[toc] | [prev] | [next] | [standalone]

#136347

jacobnavia <jacob@jacob.remcomp.fr> writes:
>Le 06/10/2018 à 05:57, Spiros Bousbouras a écrit :
>> Just what the world needs , another text editor
>

>If I would use the gnu "gdb" I would have to generate DWARF debug info, 
>what is an horrible MESS!

Why do you say that?

[toc] | [prev] | [next] | [standalone]

#136353

Le 06/10/2018 à 16:53, Scott Lurndal a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> Le 06/10/2018 à 05:57, Spiros Bousbouras a écrit :
>>> Just what the world needs , another text editor
>>
> 
>> If I would use the gnu "gdb" I would have to generate DWARF debug info,
>> what is an horrible MESS!
> 
> Why do you say that?
> 

Line numbers.

Under windows (and stabs) I just have to emit a record with line, PC 
address. Very easy. Under DWARF I have to make a virtual table to be 
decoded with a virtual machine that has its own "instruction set". That 
means I have to recreate that virtual machine when emiytting the debug 
info, and when reading it. No longer possible to make an easy line+PC 
address record any more.

Then, there are the abbreviations for commands, etc etc. It is 
incredibly complicated. I already generated info for #defines under 
windows (no other compilers did, and MSVC doesn't even today as far as I 
know) gcc doesn't either because when I type any #define MACRO under gdb 
it never recognizes it.

Then there is the frame information (that I already generate for my C++ 
interface). The problem is that the DWARF specs aren't followed neither 
by gcc nor by gdb, since they "optimized" them in undocumented ways, so 
that if you follow the specs it will never work. I arrived to the 
conclusion that the only way to do that is to generate EXACTLY what gcc 
generates, even if it is incomprehensible if you refer to the published 
DWARF specs.

One of the problems also was that the assembler has some "optimizations" 
that are nowhere documented concerning how it assembles the stack frame 
descriptions, since it will react to some bit patterns and emit 
something else to "optimize" the stack frame info.

Figuring out all this is incredibly time consuming and messy: you are at 
the mercy of the whims of gcc developers that can change everything from 
version X.01 to X.02 without you being able to complain or to understand 
why the new gcc / gdb version doesn't work anymore.

Yes, gdb understand sometimes the stabs that I generate, but it has a 
bug with 64 bit arguments using stabs, that get mangled. I sent them a 
patch for that 4-5 years ago but the bug is there today. Since they do 
not use stabs any more, they will never fix it.

Using my own debugger I know what is going on. I wrote one under 
windows. Of course in the first time I generated debug info that the 
MSVC compiler would understand (CV09 standard). But then MSVC changed in 
a whim to another (undocumented) debug info format and I was left in the 
cold of course. So, I kept the CV09 standard and wrote my own debugger.

For linux I would prefer avoiding gdb/gcc as much as possible (as I 
avoided MSVC/CodeView under windows)

[toc] | [prev] | [next] | [standalone]

#136382

jacobnavia <jacob@jacob.remcomp.fr> wrote:
> Hi folks
> 
> I tried to install the open source package "GEDIT".
> 
> It needed a Tex package, and a Tex installation, what I did download. 
> But then it needs "style sheets" (whatever that may be)
> 
> It crashed during ./autogen.sh with missing xslt-stylesheets.
> 
> So, I cloned
> git clone https://github.com/docbook/xslt10-stylesheets.git
> 
> OK
> 
> Bu then it says it needs perl package xml-xpath. I figured out that issuing
> sudo apt-get install libxml-xpath-perl
> 
> would fix that.
> 
> Then it needed to read a file called .xmlc. After an houro so searching 
> I came to see an invisible fdirectory in the download of xstyle-sheets 
> called ".trevis" and ythere I found a xmlc file. I copied that to my 
> home directory and the script went a little bit further.
> 
> A package called "xerces" was needed. I found that and wen further.
> I installed then a package that is called "saxon", that asked for money.
> Happily there is a free version, but apparently it will not work.
> 
...
> 
> If anyone can tell me how to proceed I would be thankful.
> 

On an obsolete Linux system, gedit 2.30.4 builds correctly with
./configure && make.  However, 3.8.3 fails with:

configure: error: Package requirements (
	libxml-2.0 >= 2.5.0
	glib-2.0 >= 2.28.0
	gio-2.0 >= 2.35.4
	gtk+-3.0 >= 3.7.10
	gtksourceview-3.0 >= 3.2.0
	libpeas-1.0 >= 1.7.0
	libpeas-gtk-1.0 >= 1.7.0
	gsettings-desktop-schemas
) were not met:

Requested 'gio-2.0 >= 2.35.4' but version of GIO is 2.34.3
Requested 'gtk+-3.0 >= 3.7.10' but version of GTK+ is 3.4.4
No package 'gtksourceview-3.0' found
No package 'libpeas-1.0' found
No package 'libpeas-gtk-1.0' found

Gnome is notorious for breaking APIs, so unless you want a full Gnome
system, I'd avoid Gedit - or find a 2.x version, which may be easier
to install.  Or check the Elvis source code, if that's your interest.
No modern software documents its structure particularly well; the
documentation is now intended for users, not programmers.

Will

-- 
Unprovided with original learning, unformed in the habits of thinking,
 unskilled in the arts of composition, I resolved to write a book.
  -- Edward Gibbon

[toc] | [prev] | [next] | [standalone]

#136383

On 2018-10-05, jacobnavia <jacob@jacob.remcomp.fr> wrote:
> Hi folks
>
> I tried to install the open source package "GEDIT".

Gedit is part of Gnome, so you will need Gnome of particular version.
Try editor that is standalone.

-- 
press any key to continue or any other to quit...

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web