Announcement

Collapse
No announcement yet.

Enlightenment's Terminal Gets New Features

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

  • #21
    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


    • #22
      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


      • #23
        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


        • #24
          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


          • #25
            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


            • #26
              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


              • #27
                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