On Tue, 19 Jun 2012 21:13:25 +1000 David Seikel <onef...@gmail.com> said:
> On Tue, 19 Jun 2012 19:24:20 +0900 Carsten Haitzler (The Rasterman) > <ras...@rasterman.com> wrote: > > > On Mon, 18 Jun 2012 21:54:23 -0300 Gustavo Sverzut Barbieri > > <barbi...@profusion.mobi> said: > > > > > On Sun, Jun 17, 2012 at 10:27 PM, Carsten Haitzler > > > <ras...@rasterman.com> wrote: > > > > On Sun, 17 Jun 2012 21:43:05 -0300 Gustavo Sverzut Barbieri > > > > <barbi...@profusion.mobi> said: > > > > > > > > there are some gfx mode thgins in escapes. i assume thats used to > > > > draw lines using special line characters as it remaps regular > > > > chars to these sequences when in that mode - i think. i've never > > > > tried the menuconfig/ncurses lines thing in terminiology, so > > > > don't know. > > > > > > Thanks to KainX and his expertise I was able to get it working. > > > There is now a vt100 to unicode table I got from urxvt. The key was > > > to understand it may change the charset to DEC's ACS. > > > > hmm i am still missing them from jed - must be a different set of gfx > > chars... it's on a mental todo list to look into it. > > That seems to be a pain involving code pages, or something else that > seems be terminal specific sometimes. I've still not figured out how to > drive line drawing generically in my terminal app. No, I don't want to > use ncurses, it's too bloated. I'm trying to make an ncurses > alternative that is not bloated. yes - i saw the codepage escapes - i dont know what to do with them currently. > My theory is that you can do 99% to 100% of what you need to do using > just a few basic ANSI escape sequences. Only a few decades old serial > terminals would need anything different. Most of those ANSI sequences > are historical bloat that's not needed. Though a terminal would need > to support a large percent of them, a program running on a terminal > wont. I'm making a tiny library for those programs running on a > terminal. > > So far I'm getting good results with a surprisingly little bit of code, > but it's early days yet. Even mature programs can't always cope with > these box / line "graphics". > > On the other hand, I've not researched some of this much, only just > started it on the weekend. > > Yes, it worked fine on terminology out of the box. B-) > > > > >> - multiple windows and/or tabs > > > > > > > > right now this is right on the end of a list of features as > > > > frankly i'm not happy with the 1 process goes down and ALL my > > > > terminals go thing that gnome-terminal does. as for tabs - don't > > > > use TABS... be imaginative. i was thinking a thumbnail-like > > > > chooser - wp2 style with a quick select bar with smaller thumb on > > > > mouseover the top of the term or something. > > > > > > well, if you have tabs you need fast switch AND fast lookup where > > > you are. So far nothing beats visual tabs for that. > > > > if we make the theme allow for this on signals and swallows then i > > might entertain it - i still think its too early given stability > > issues. but no bar of tabs by default. option. > > > > > The switch often happens with shortcut... so invisible. But the > > > lookup > > > > that's fine. the intent was to have shortcuts eventually be able to go > > next/prev term, bring up a grid of them u can then arrow-key select > > etc. > > > > > where you are you can easily see with the tab position as in an > > > actual physical file/archive. You also need hints of visual bells > > > or alarms on other tabs -- tabs are usual and unbeatable as people > > > are used to it, even with screen. > > > > > > IOW: let's use the fancyness for other elements, like the wallpaper > > > and font choosers? > > > > we can do better than tabs - and i want to try. > > If you mean something like what passes for tabs in elementary, please > don't. It's on no way shape or form "better". At least the way I > found to do "tabs" so far on elementary, there was no obvious "plain > old ordinary tabs" that I found. That was a pain in elementary, and I'm > not happy with the results. no - i dont want that. i want to do something more like wp2. > Sometimes you just want plain old ordinary tabs, just like everyone > else does tabs. There's good reasons for that. You can get fancy, > and "do better", but please provide plain old ordinary tabs just like > everyone else does first. > > > > >> - made it possible to specify the font preview string, with > > > >> some PITA chars by default (Ox0, 1xl).. It works, but height is > > > >> not resizing properly :-/ > > > > > > > > oooh... do we REALLY want that there all the time? its a waste of > > > > space and people will barely ever change it. putting that in > > > > another "tab" might be more useful and space efficient. > > > > > > The most annoying bit that leads one to change terminal fonts is due > > > some specific glyphs -- that we can't predict. Some people dislike > > > lowercase-L as it looks like 1. Some uppercase-O x zero. Some use it > > > to detect subtle differences with "a"... > > > > then change the default string - but the entry box doesn't belong in > > that pane/dialog. there is precious little enough space as-is. an > > entry that you almost NEVER change the content of doesn't belong > > there. in fact the fact that u covered up all of the terminal with > > the dialog is the problem as u no longer see the preview - that's > > why i left a gap on the left side to see the terminal content itself > > when the font changed. > > > > > IOW: letting the user choose a font without trying is just strange. > > > Yes, one can change and see the feedback on the background termio, > > > but that's annoying to have to do it :-/ > > > > just make the default string more useful. you have a point about l vs > > 1 and 0 vs O and so on. :) if you really want a custom string thing - > > put it in another place to edit so it doesn't continually eat up > > space for the 99.9% of the time u never edit/change it and you want > > to see more fonts instead. :) > > If it's showing the font changes in real time as you select fonts, on > the actual terminal squished to one side, like I think you are saying > (not played with that bit yet), then that's a great substitute for being > able to provide a string to see the font changes in. I'd vote for the > former over the later. Coz when someone wants to experiment with > changing the font, chances are it's coz something already on their > terminal right now is showing up "wrong". it already does this. thats why i made the selector thinner again so u can see the changes poking out on the left the bigger ur term the more u see live. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
