|
Soricidus posted:also idk about p3's, maybe if you kept modern gpus so there would be something that could handle hd video decoding. certainly true that the habit of doing everything in js or python or whatever instead of writing in a compiled language like a grown-up has led to software getting exponentially slower without offering anything like exponential gains in usability or features. I'm sorry, my time is infinitely more valuable to me than a few extra hundred thousand CPU cycles.
|
#
?
Jul 28, 2015 19:46
|
|
|
|
| # ? Mar 20, 2025 05:32 |
|
|
NE ways, you can either link to c code or if you want to use a language where you don't have to artisnally craft ur data structures with each project start a sub-process to do the real work. In a freaking event driven GUI the app is sitting there idle 99.99% of the time. Using a compiled language is a premature optimization these days in my book.
|
|
#
?
Jul 28, 2015 19:48
|
|
|
N NE case, the small compiled language applications have been written years ago and there isn't much of a need for new versions. It doesn't get much lower resource usage than irssi and "please only send me plain text emails" mutt.
|
|
#
?
Jul 28, 2015 19:52
|
|
|
so youre saying to make gui stuff in js right
|
|
#
?
Jul 28, 2015 19:57
|
|
|
pram posted:so youre saying to make gui stuff in js right It worked well in 2005. You could link IE into your vc++ application, write the interface in html and JS with callbacks to the c++ code that did the real work. It was pretty sweet being able to use a technology geared to layouts and aesthetics.
|
|
#
?
Jul 28, 2015 20:03
|
|
|
sounds like poo poo arent you supposed to use wpf or winforms anyway. you're writing c++ code, and writing your gui in javascript. when windows has multiple native toolkits. lol
|
|
#
?
Jul 28, 2015 20:05
|
|
|
pram posted:sounds like poo poo Oh yeah, one came out in 2006 and AFAIK the 2003 winforms required C++.net. Counterpoint, you can hire a designer that isn't poo poo, they can work with the tools they are used to, and in 2002-2006 you could make a gui that kicked the poo poo out of anything people were making in MFC.
|
|
#
?
Jul 28, 2015 20:18
|
|
|
this is how we end up with poo poo like the spotify client
|
|
#
?
Jul 28, 2015 20:20
|
|
|
just use c# and wpf or winforms even, jesus
|
|
#
?
Jul 28, 2015 20:23
|
|
|
Cold on a Cob posted:just use c# and wpf or winforms even, jesus SYSV Fanfic posted:It worked well in 2005. You could link IE into your vc++ application SYSV Fanfic posted:You could link IE into your vc++ application SYSV Fanfic posted:2005. vc++ application SYSV Fanfic posted:vc++ vc++
|
|
#
?
Jul 28, 2015 20:26
|
|
|
SYSV Fanfic posted:It worked well in 2005. You could link IE into your vc++ application, write the interface in html and JS with callbacks to the c++ code that did the real work. It was pretty sweet being able to use a technology geared to layouts and aesthetics. html is not a technology geared to layouts and aesthetics. it's a technology geared to structured text with hyperlinks to other structured text. using html+js to build a gui is about as sensible as using emacs+elisp (which i have also seen, and works about as well as you'd expect)
|
|
#
?
Jul 28, 2015 20:34
|
|
|
SYSV Fanfic posted:vc++ yeah i stand by my post 
|
|
#
?
Jul 28, 2015 20:35
|
|
|
SYSV Fanfic posted:It worked well in 2005. You could link IE into your vc++ application, write the interface in html and JS with callbacks to the c++ code that did the real work. It was pretty sweet being able to use a technology geared to layouts and aesthetics. 
|
|
#
?
Jul 28, 2015 20:45
|
|
|
carry on then posted:
all of the normal-user applications on my linux desktop right now would happily run on a dual P3 it would be unbearably slow to compile stuff though
|
|
#
?
Jul 28, 2015 21:02
|
|
|
Compilers have to have been hitting diminishing returns in their optimization algorithms for a decade or so otherwise code would have been unbearably slow back in the Pentium III days: slow because it was running on a Pentium III and then slower still because it was compiled on the sort of compiler that would have to run on a Pentium III (and the few hundred MB of memory that would have had) Then again computers have been "fast enough" since like the mid 00s or so. SSDs made programs start up fast, and plentiful VRAM has given us double buffered desktop UIs with acceptable responsiveness (and once  Wayland is finally production ready then Linux UI toolkits will leap fully into the double-buffered tear-free world). Also, 8GB of RAM really is enough for just about any non-specialist application, and has been for quite a while. Eclipse, the bloated piece of poo poo that it is, still only uses 1GB of memory on my laptop, and I think most of that is because the Git plugin has some sort of horrible memory and UI resource leak in it compounded by SWT's GTK3 backend.The very first release of OS X had a double-buffered composited UI, and it was also unbearably slow because the hardware of the time wasn't quite ready for it.
|
|
#
?
Jul 28, 2015 21:14
|
|
|
I'm running gtk3-git and clutter-git atm but then I tried compiling mutter-git and running it in Wayland mode and that doesn't do anything other than segfault at the console  sitting here w/ my dick in my hand and a serious case of blue balls here. i just wanna run GNOME 3 w/ that compositor patch that finally fixes HiDPI under wl, everything else seems to work afaict
|
|
#
?
Jul 28, 2015 21:17
|
|
|
4 GB has been a practical requirement for a unix workstation for like 15 years now back in the 1990s linux beardos would always brag about how a slow PC could run linux pretty good. and they were right. but they didn't mention that it would use 2x or 4x or 8x as much RAM as windows thankfully now your OS ram doesn't matter. chrome consumes all available memory so all platform-related differences look really small by comparison
|
|
#
?
Jul 28, 2015 22:03
|
|
|
please use pythong and kde] thx
|
|
#
?
Jul 28, 2015 22:03
|
|
|
ZShakespeare posted:please use pythong Gross
|
|
#
?
Jul 28, 2015 22:05
|
|
|
Mr Dog posted:I'm running gtk3-git and clutter-git atm but then I tried compiling mutter-git and running it in Wayland mode and that doesn't do anything other than segfault at the console if you're on fbcon then you need to pass "mutter --wayland --display-compositor"
|
|
#
?
Jul 28, 2015 22:19
|
|
|
Soricidus posted:html is not a technology geared to layouts and aesthetics. it's a technology geared to structured text with hyperlinks to other structured text. using html+js to build a gui is about as sensible as using emacs+elisp (which i have also seen, and works about as well as you'd expect) im not a coputer professionbal but i have made cam whole web sites and heres a fact tables are all u need for swag layout and aethetics peace out
|
|
#
?
Jul 28, 2015 22:46
|
|
|
bootstrap is fail. scrolling poo poo. loving sucky
|
|
#
?
Jul 28, 2015 22:47
|
|
|
Smythe posted:im not a coputer professionbal but i have made cam whole web sites and heres a fact tables are all u need for swag layout and aethetics peace out if you use tables the nerds will sneer at you do you want to be sneered at by nerds, smythe?
|
|
#
?
Jul 28, 2015 23:05
|
|
|
the very forum we are posting on now is based on tables
|
|
#
?
Jul 28, 2015 23:07
|
|
|
and im pretty sure the nerds sneer at it
|
|
#
?
Jul 28, 2015 23:18
|
|
|
it drives me fuckin nuts that kde 5 abandons the xembed / fd.o system tray. the one god drat thing that has worked properly for fifteen years is now broken on both of the major desktop packages: gnome 3 and kde 5. i expect this kind of horseshit from gnome but it is an unwelcome surprise in the kde camp
|
|
#
?
Jul 29, 2015 05:15
|
|
|
i understand why the xembed model for system trays sucked poo poo. but why did they not provide backwards compatibility? let new apps work with your cool stuff, and provide a second system tray for legacy fd.o/xembed compatibility. kde usually falls back on compatibility and more settings rather than less. that's the spirit i was familiar with. and here i'm confronted with a seriously nasty breaking change
|
|
#
?
Jul 29, 2015 05:17
|
|
|
Suspicious Dish posted:if you're on fbcon then you need to pass "mutter --wayland --display-compositor" well i finally got it to work had to write a PKGBUILD for gnome-shell-git and then it turns out that you have to run glib-compile-schemas too or some poo poo so i just did that manually then recompiled everything so that all the APIs lined up from gtk3-git on up trip report: i guess a bunch of DBus and/or GSettings is semi not working? like the top bar says org.gnome.Terminal instead of Terminal Emulator (and the dock icon is a generic icon), fonts are completely hosed up (hurr fonts on linux :slidewhistle: ) touchpad under libinput is ....... different but holy poo poo palm detection actually loving works now mouse cursor is half the size when over any window that isn't part of gnome shell everything seems to use way more CPU now, ironically enough. this doesn't seem smoother. it's almost usable day-to-day and i suspect most of this breakage is a consequence of my ham-fisted pawing trying to compile stuff on the bleeding edge and then stuff it into a package format i don't fully understand
|
|
#
?
Jul 29, 2015 05:51
|
|
|
Mr Dog posted:well i finally got it to work 2015 year of linux on the desktop
|
|
#
?
Jul 29, 2015 05:55
|
|
|
pram posted:2015 year of linux on the desktop 2015 might be the year of Wayland on the linux desktop but it's gonna be a close one anyway yeah obviously i'm building bleeding edge poo poo from Git i'm not expecting a particularly sublime and polished experience here
|
|
#
?
Jul 29, 2015 05:57
|
|
|
Mr Dog posted:well i finally got it to work sounds like you hosed up
|
|
#
?
Jul 29, 2015 06:36
|
|
|
Mr Dog posted:The very first release of OS X had a double-buffered composited UI, and it was also unbearably slow because the hardware of the time wasn't quite ready for it. nah, it wasn't ready for the hardware. same hardware did much better once 10.2 and especially 10.3 rolled around. every transparency/scale effect in 10.0 was rasterized on the cpu. iirc the only support for acceleration in that timeframe was simple solid bitblit (and maybe not even that much in 10.0? gently caress it's been a long time, used to know this osx nerd trivia so well) if anything the 10.0 window server was astonishingly fast given that gpu acceleration was years away the real perf issue was that just about every other layer of the os was poorly optimized and/or buggy including the fs.
|
|
#
?
Jul 29, 2015 07:43
|
|
|
Soricidus posted:computers will never be easy to use for normal humans until you can just talk to them normally and they understand you and do what you want so they have to literally be better than people
|
|
#
?
Jul 29, 2015 08:16
|
|
|
Suspicious Dish posted:sounds like you hosed up i suppose. i mean i am using linux, that's a pretty big fuckup right there
|
|
#
?
Jul 29, 2015 14:17
|
|
|
pram posted:this is how we end up with poo poo like the spotify client isn't the spotify client made in flash? feels like it anyway.
|
|
#
?
Jul 29, 2015 15:14
|
|
|
no its made with this https://en.wikipedia.org/wiki/Chromium_Embedded_Framework
|
|
#
?
Jul 29, 2015 15:24
|
|
|
github's atom editor embeds an entire web browser engine because the editor itself is basically a web app.
|
|
#
?
Jul 29, 2015 15:38
|
|
|
i want to make an editor that's a web browser engine running atom's web browser via emscripten and using suspicious dish's javascript x server to display it
|
|
#
?
Jul 29, 2015 20:11
|
|
|
Soricidus posted:i want to make an editor that's a web browser engine running atom's web browser via emscripten and using suspicious dish's javascript x server to display it we have to go deeper
|
|
#
?
Jul 29, 2015 23:37
|
|
|
|
| # ? Mar 20, 2025 05:32 |
|
|
its javascript x running on top of javascript pdp-11
|
|
#
?
Jul 29, 2015 23:44
|
|