Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 29

Thread: Enlightenment's Terminal Gets New Features

  1. #11
    Join Date
    Aug 2011
    Posts
    516

    Default

    Quote Originally Posted by siavashserver View Post
    On Arch Linux trying to pacman -Rnsc glib2 or pacman -Rnsc cairo results in removal of the whole KDE desktop
    Yeah, in hindsight, it's probably impossible to get a KDE desktop sans glib/gtk dependency these days without compiling everything yourself. QtCore will try to build with glib based mainloop support by default, and I think the gtk style for QtWidgets comes by default as well.

  2. #12
    Join Date
    Mar 2013
    Posts
    144

    Default

    Quote Originally Posted by dh04000 View Post
    Something I've never gotten is WHY each desktop environment feels like needs to build a terminal off of their libraries. Why isn't there an non-desktop linked standard terminal so we can all move on?
    A stand alone terminal will need to duplicate a whole lot of functionality the GUI tool kits already implement. i.e. If you wanted a stand alone Terminal, you'd need to write a font rendering library, an abstraction around the native APIs (X and Wayland for linux, USER\MFC\.Net\Metro for Windows...), something for concurrency, something to handle mouse input, audio output for the beeps and such, maybe an image library to go beyond vt100... Essentially, you'll be writing a fair sized GUI Tool Kit even before starting.

    Historically, GTK started in much the same way: it originates from GIMP as the widgets were fractured out into a library. Only Qt was conceived as a C++ GUI Tool Kit right from the start. Similarly, EFL originates from the Enlightenment developers who, after the original DE, decided they need to start from the libraries and work their way up.

    Currently, all the libraries are now mostly capable separate entities that offer a whole suit of functionalities. e.g. They all have an internal threading approach\implementation. And they all abstract the native APIs completely so in principle it's possible to write cross platform applications.

  3. #13
    Join Date
    Jan 2011
    Posts
    98

    Default

    Real terminal emulators? There is only XTerm.

  4. #14
    Join Date
    Feb 2008
    Location
    Linuxland
    Posts
    5,062

    Default

    Quote Originally Posted by c117152 View Post
    A stand alone terminal will need to duplicate a whole lot of functionality the GUI tool kits already implement. i.e. If you wanted a stand alone Terminal, you'd need to write a font rendering library, an abstraction around the native APIs (X and Wayland for linux, USER\MFC\.Net\Metro for Windows...), something for concurrency, something to handle mouse input, audio output for the beeps and such, maybe an image library to go beyond vt100... Essentially, you'll be writing a fair sized GUI Tool Kit even before starting.
    Mouse? Threading? Why would you need those?

    The rest is far from that complex. Beeps are done by emitting a special char. Font rendering is one call per line to Xft. The only somewhat complex part is emulating all the weird terminals - if you don't care for that, it's quite simple.

  5. #15
    Join Date
    Jul 2013
    Posts
    371

    Default

    Quote Originally Posted by c117152 View Post
    A stand alone terminal will need to duplicate a whole lot of functionality the GUI tool kits already implement. i.e. If you wanted a stand alone Terminal, you'd need to write a font rendering library, an abstraction around the native APIs (X and Wayland for linux, USER\MFC\.Net\Metro for Windows...), something for concurrency, something to handle mouse input, audio output for the beeps and such, maybe an image library to go beyond vt100... Essentially, you'll be writing a fair sized GUI Tool Kit even before starting.
    Or, get this, they could make a "core" backend that can be used with different front-ends (see: limetext). This way, each DE could, if they wanted, make their own fancy front-end using their favorite toolkit but all would contribute to the same back-end.
    Supporting X and Wayland would be pretty simple at that point...

  6. #16
    Join Date
    Mar 2013
    Posts
    144

    Default

    Quote Originally Posted by curaga View Post
    Mouse? Threading? Why would you need those?
    Tabs, Copy-pasting...

    Quote Originally Posted by curaga View Post
    The rest is far from that complex. Beeps are done by emitting a special char.
    Which the emulator needs to translate into sound. Last I've checked linux's sound was multi headed hydra that needs big fat libraries just to output a simple beep.

    Quote Originally Posted by curaga View Post
    Font rendering is one call per line to Xft.
    xft as in the X Font library,,, A library dependency specifically for X. i.e. no Wayland for you.

    Quote Originally Posted by curaga View Post
    The only somewhat complex part is emulating all the weird terminals - if you don't care for that, it's quite simple.
    What's weird about wanting UTF-8 unicode support in the terminal? There is serious work being done on both user land and in the kernel for the last couple of years: http://www.freedesktop.org/wiki/Software/kmscon/ . Hopefully once it lands in a distribution near you, you will see why it's useful. I personally had the "pleasure" of trying to delete foreign named files over SSH and serial ports on multiple occasions. As you might imagine, it was quite frustrating.

    Quote Originally Posted by Daktyl198 View Post
    Or, get this, they could make a "core" backend that can be used with different front-ends (see: limetext). This way, each DE could, if they wanted, make their own fancy front-end using their favorite toolkit but all would contribute to the same back-end.
    Supporting X and Wayland would be pretty simple at that point...
    http://xkcd.com/927/

    Are you new to linux?
    Last edited by c117152; 12-09-2013 at 03:10 PM.

  7. #17
    Join Date
    Apr 2010
    Posts
    717

    Default

    Quote Originally Posted by curaga View Post
    The only somewhat complex part is emulating all the weird terminals - if you don't care for that, it's quite simple.
    I thought we were talking about building a common terminal emulator that everyone could use, regardless of their favourite desktop? What you seem to be talking about is having one that provides just the functions you need, and never mind other people....

  8. #18
    Join Date
    Aug 2011
    Posts
    516

    Default

    Quote Originally Posted by Daktyl198 View Post
    Or, get this, they could make a "core" backend that can be used with different front-ends (see: limetext). This way, each DE could, if they wanted, make their own fancy front-end using their favorite toolkit but all would contribute to the same back-end.
    Supporting X and Wayland would be pretty simple at that point...
    I don't get how that would affect supporting X/Wayland. In fact, it would be orthogonal to that. Supporting windowing systems is the toolkit's job.

  9. #19
    Join Date
    Sep 2012
    Posts
    665

    Default

    Quote Originally Posted by curaga View Post
    Mouse? Threading? Why would you need those?

    The rest is far from that complex. Beeps are done by emitting a special char. Font rendering is one call per line to Xft. The only somewhat complex part is emulating all the weird terminals - if you don't care for that, it's quite simple.
    Copy paste?

  10. #20
    Join Date
    Mar 2012
    Posts
    25

    Default

    Quote Originally Posted by dh04000 View Post
    Something I've never gotten is WHY each desktop environment feels like needs to build a terminal off of their libraries.
    Well, those libraries give the terminal abilities that would normally not be possible.

    For example, with terminology, you can view and run multimedia files. See http://www.youtube.com/watch?v=ibPziLRGvkg .

    It has more unique features, but those shown in the video are certainly some of the more interesting ideas.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •