Announcement

Collapse
No announcement yet.

Enlightenment's Terminal Gets New Features

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by curaga View Post
    Mouse? Threading? Why would you need those?
    Tabs, Copy-pasting...

    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.

    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.

    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.

    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, 03:10 PM.

    Comment


    • #17
      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....

      Comment


      • #18
        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.

        Comment


        • #19
          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?

          Comment


          • #20
            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.

            Comment


            • #21
              Originally posted by c117152 View Post
              http://xkcd.com/927/

              Are you new to linux?
              lol no, I was just providing a solution to before :P

              Originally posted by Ancurio View Post
              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.
              I think you should tell the people over at Gnome. Apparently, they don't know it since after they ported GTK to work on Wayland, most of their apps still didn't work!! /s
              There can be X-specific calls within the application as well, not going through the toolkit. There are a lot of applications with this, actually, since most people came to expect X11 to be on every Linux desktop...

              Comment


              • #22
                Originally posted by Daktyl198 View Post
                There can be X-specific calls within the application as well, not going through the toolkit. There are a lot of applications with this, actually, since most people came to expect X11 to be on every Linux desktop...
                That's curious.. what could you possibly do with Xlib that is not connected to the windowing system?

                Comment


                • #23
                  Originally posted by DeeK View Post
                  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.
                  That's kinda cool.


                  I seem to have upset people with my comment about about WHY do we need more terminals, and like usual, they went 90 different directions with it. So let me better define.

                  I'm fine with the terminals using the gtk, or qt, or efl, or whatever you want tool kit the devs want to us. I just hate that I have to download large portion of a desktop environment in order to use a simple terminal or note taking application. I want apps to be stand-alone from the desktop environment libraries, but the tool kit itself is fine.

                  Comment


                  • #24
                    Originally posted by dh04000 View Post
                    I'm fine with the terminals using the gtk, or qt, or efl, or whatever you want tool kit the devs want to us. I just hate that I have to download large portion of a desktop environment in order to use a simple terminal or note taking application. I want apps to be stand-alone from the desktop environment libraries, but the tool kit itself is fine.
                    And several people already answered you: Terminal: xterm. Note taking: xterm+vim.

                    Comment


                    • #25
                      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?
                      it's called xterm. or rxvt. or urxvt. The fact is that these don't LOOK like they fit and miss most of the fancy features everyone now expects. And maybe you didn't look - Terminology is much more than just "yet another terminal". It does what few others do. It does tabs AND pane splits. It does inlined images (you cat cat images, videos, pdf's, and more). It can do an ls that does thumbnails... It's EXTENDING terminal escapes. Other terminal efforts are in the most part not bothering here and simply re-doing the same thing everyone has done (mostly). Terminology is doing... embrace and extend.

                      Comment


                      • #26
                        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.
                        mouse? why? terminals need to provide mouse feedback to terminal apps. there are vt escapes for enabling this and most terminals support it. it's also how you do selections... or click on links... and more. so no matter what - you need it. if YOU don't USE it... that's up to you, but it's needed.

                        Comment


                        • #27
                          Originally posted by dh04000 View Post
                          That's kinda cool.


                          I seem to have upset people with my comment about about WHY do we need more terminals, and like usual, they went 90 different directions with it. So let me better define.

                          I'm fine with the terminals using the gtk, or qt, or efl, or whatever you want tool kit the devs want to us. I just hate that I have to download large portion of a desktop environment in order to use a simple terminal or note taking application. I want apps to be stand-alone from the desktop environment libraries, but the tool kit itself is fine.
                          have you ever written software? any decently complicated bit of software? i take that as a no. when you write an app - a complex gui app and a terminal counts as a complex one, MOST of the app is BOUND to its toolkit. to have it be generic and support many toolkits literally multiplies the work by N where N is the number of toolkits to support. effectively thats the case (or close to it). not only does it multiple the code.. it means the devs have to LEARN several other toolkits too. thats not just the work of writing code for a toolkit they know but LEARNING the others too. THEN comes the point where different toolkits work differently. some make certain things harder or easier. some just work in entirely different ways where in one toolkit it's trivial to do and in another you have to re-implement the features yourself in your code as the toolkit lacks them. and that's jut the work to BUILD suport for N toolkits. THEN you need to MAINTAIN that. fix bugs. etc. etc.

                          really. you live in an unrealistic world. you should write a non-trivial application some day.

                          Comment


                          • #28
                            Originally posted by raster View Post
                            have you ever written software? any decently complicated bit of software? i take that as a no. when you write an app - a complex gui app and a terminal counts as a complex one, MOST of the app is BOUND to its toolkit. to have it be generic and support many toolkits literally multiplies the work by N where N is the number of toolkits to support. effectively thats the case (or close to it). not only does it multiple the code.. it means the devs have to LEARN several other toolkits too. thats not just the work of writing code for a toolkit they know but LEARNING the others too. THEN comes the point where different toolkits work differently. some make certain things harder or easier. some just work in entirely different ways where in one toolkit it's trivial to do and in another you have to re-implement the features yourself in your code as the toolkit lacks them. and that's jut the work to BUILD suport for N toolkits. THEN you need to MAINTAIN that. fix bugs. etc. etc.

                            really. you live in an unrealistic world. you should write a non-trivial application some day.
                            Way to not read, at all.
                            He said that toolkits are understandable (toolkits are separate from the DE), he's talking about, for instance, downloading Konsole. It requires downloading at least 5 KDE libs last I checked (a few of which are HUGE).

                            A simple example: I download and install Konversation on Linux Mint. It pulls in... I don't know, 7 or 8 KDE libs? The libs alone take up almost a GB once installed.
                            Then, a few months later, I go to install a app not related to KDE in any way, but apt notices that I have some core KDE libs installed, so pulls in EXTRA KDE DEPENDENCIES for this app that I don't need at all.

                            Stuff like that (which is completely separate from the toolkit) is fking annoying.

                            Comment


                            • #29
                              Originally posted by Daktyl198 View Post
                              Way to not read, at all.
                              He said that toolkits are understandable (toolkits are separate from the DE), he's talking about, for instance, downloading Konsole. It requires downloading at least 5 KDE libs last I checked (a few of which are HUGE).

                              A simple example: I download and install Konversation on Linux Mint. It pulls in... I don't know, 7 or 8 KDE libs? The libs alone take up almost a GB once installed.
                              Then, a few months later, I go to install a app not related to KDE in any way, but apt notices that I have some core KDE libs installed, so pulls in EXTRA KDE DEPENDENCIES for this app that I don't need at all.

                              Stuff like that (which is completely separate from the toolkit) is fking annoying.
                              i did read. those kde libs are part of the toolkit. from the view of a softeware developer. they provide features and services beyond what qt alone does. it's the same for gtk + gnome libs. efl itself is a different story as the core widget set is ALSO done by the same people doing all the "kde/gnome" libs equivalents. it is (in 1.7 and before) distributed as a very fine-grained split, unlike qt/gtk land where each is bigger. as of efl 1.8 it has now become more monolithic - but ALL the libs are part of the toolkit. trying to write something to be desktop agnostic means making it toolkit agnostic. this means giving up features. often many of them. and ultimately re-implementing them yourself.

                              an example - terminology allows for video wallpapers, inlined content etc. - this comes almost "for free" because one of the efl libs (emotion) does that all for you. you do very little work yourself in your app. beyond some high-level "create video obj - play/pause, seek to pos x, set volume to y" that's it. in he qt world that doesn't exist IN qt (as best i know) and that's why phonon exists - and that's part of kde. you couldn't have such a feature without then importing kde. in gnome-land you'd have to use gstreamer directly - and its not "part of gtk". these are PART of your toolkit. you can't have your features FROM the toolkit itself without REPLICATING those other libs too.

                              and if you read his first post - not wanting it desktop linked MEANS not wanting it linked to a specific toolkit as specific toolkits ARE linked to desktops. plain and simple.

                              Comment

                              Working...
                              X